Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

$ dmesg | grep isolation

[ 0.000000] Kernel/User page tables isolation: enabled



sort by: page size:

Interestingly I get:

    dmesg -H | grep 'page tables isolation'
    [  +0.000000] Kernel/User page tables isolation: enabled

    grep cpu_insecure /proc/cpuinfo && echo "Patched" || echo "Unpatched!"
    Unpatched!

    cat /proc/cpuinfo | grep pti
    fpu_exception	: yes

    uname -a
    Linux host 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux
So page tables isolation seems to be enabled but neither the pti flag nor the cpu_insecure bug is in cpuinfo.

EDIT: Maybe this is because it is Xen guest. Do I need pti on a XEN guest if the host is fully patched?


Page Table Isolation has been backported to 4.14.12, so no need to test with the rc.

From the merge commit:

  +#ifdef CONFIG_PAGE_TABLE_ISOLATION
  +# define DISABLE_PTI		0
  +#else
  +# define DISABLE_PTI		(1 << (X86_FEATURE_PTI & 31))
  +#endif
PS - MSFT has not published relnotes, so we do not know yet. We'll find out soon enough.

You can't enforce real isolation in user mode, you need the kernel to do it.

The Unix process, with its uids, is also a form of isolation. But most reasonable people would guess that there are undiscovered privilege escalation bugs in any given kernel and thus be careful who is allowed to put code on a machine.

We have a secure computing environment, it's called process isolation and it's provided by the kernel.

This is effectively first party isolation. It's buried in about:config as it breaks too many sites apparently

Are there writeups about this isolation feature? I was left wondering if it's a security boundary, like sandboxing, or a packaging system feature.

What about execution isolation? Any info?

Forgive me, I'm new to this - but wouldn't the mitigation status also depend on the distribution?

It doesn't paint AMD in any better of a light, but it may not be so dire.

The distributions at the top don't usually run a mainstream [vanilla] kernel. Consequently, neither do their children/derivatives.

For example, the kernel configs for my distribution (Fedora 35) show it as enabled - unless I'm missing some further step:

    $ zgrep CONFIG_PAGE_TABLE_ISO /boot/config-`uname -r`
    CONFIG_PAGE_TABLE_ISOLATION=y
I ask and remain somewhat curious partly because I don't see the messages in the ring buffer I'd expect

(based on some cursory research)


You could break out of the isolation by using kernel vulnerabilities, e.g., in syscalls.

No. Isolation has always been a security feature, not a reliability feature.

Consider that local privilege escalations are generally (and I'd say correctly) treated as critical severity issues. Any general purpose process memory read-isolation leak is a quick route to a local privilege escalation, so how could isolation be anything other than a security feature? In its absence, you might as well run everything as root and there would be no point whatsoever to caring about privilege escalations.


Didn't know about this Physical Isolation feature[0] before. Does anyone have any idea how reliable this is?

[0]: https://www.whonix.org/wiki/Dev/Build_Documentation/Physical...


There was something written lately about how X does not do isolation, at all, easily letting people capture keyboard input that was being typed into a terminal during the sudo prompt.

A screensaver would not be immune to this as well when run in userland, in fact the same session.

I think there should be more isolations in place for cases like this.


It would be useful to dostinguish how this different or improves on other oses using isolation.

If you enable the First-Party Isolation preference in about:config then this is more effective site isolation and is automatic for all sites.

So what?

Site isolation is a huge win.


There is (most likely) no perfect isolation.

If given no alternatives, a kernel should burn down rather than permitting a privilege escalation. Ideally there is no privilege escalation either.

Given bad input the kernel should not fault but sometimes it must.


Any solution requires "crippling the software" - process isolation increases overhead through kernel context switches
next

Legal | privacy