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

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


sort by: page size:

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.

$ dmesg | grep isolation

[ 0.000000] Kernel/User page tables isolation: enabled


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?


Yes, but execute disable is not the same as execute only. AFAIK there's no way to prevent executable pages from being readable using only the i386/amd64 page table.

What about execution isolation? Any info?

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...


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

Somebody posted the documentation of stack isolation in another thread.

If you want exactly that, and only that, my conclusion is that the best way is to use `isolation: isolate`.


So what?

Site isolation is a huge win.


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.


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)


It's not. They're just using the term as a synonym for "rewrite". There's no documentation of any actual IP isolation in the linked article. They just want people to know it's new and not based on the existing LLVM or Linux runtimes.


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

The PROT_WRITE tweak is interesting. Being able to enforce a bit of Write XOR Execute behavior in Write OR Execute arenas is nifty. It took this change for me to read into W^X and exactly what it entailed because my naive understanding was that the new no-syscall-from-writeable-page behavior would be almost identical in effect to the strict W^X behavior.

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

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

I believe the 'First-party isolation' feature does this, but you need to enable it from about:config, and even then, I'm not sure if it is complete or bug-free.

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.

next

Legal | privacy