SMEP emulation in PTI
source link: https://outflux.net/blog/archives/2018/01/04/smep-emulation-in-pti/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
January 4, 2018
An nice additional benefit of the recent Kernel Page Table Isolation (
CONFIG_PAGE_TABLE_ISOLATION) patches (to defend against CVE-2017-5754, the speculative execution “rogue data cache load” or “Meltdown” flaw) is that the userspace page tables visible while running in kernel mode lack the executable bit. As a result, systems without the SMEP CPU feature (before Ivy-Bridge) get it emulated for “free”.
Here’s a non-SMEP system with PTI disabled (booted with “
pti=off“), running the
EXEC_USERSPACE LKDTM test:
# grep smep /proc/cpuinfo # dmesg -c | grep isolation [ 0.000000] Kernel/User page tables isolation: disabled on command line. # cat <(echo EXEC_USERSPACE) > /sys/kernel/debug/provoke-crash/DIRECT # dmesg [ 17.883754] lkdtm: Performing direct entry EXEC_USERSPACE [ 17.885149] lkdtm: attempting ok execution at ffffffff9f6293a0 [ 17.886350] lkdtm: attempting bad execution at 00007f6a2f84d000
No crash! The kernel was happily executing userspace memory.
But with PTI enabled:
# grep smep /proc/cpuinfo # dmesg -c | grep isolation [ 0.000000] Kernel/User page tables isolation: enabled # cat <(echo EXEC_USERSPACE) > /sys/kernel/debug/provoke-crash/DIRECT Killed # dmesg [ 33.657695] lkdtm: Performing direct entry EXEC_USERSPACE [ 33.658800] lkdtm: attempting ok execution at ffffffff926293a0 [ 33.660110] lkdtm: attempting bad execution at 00007f7c64546000 [ 33.661301] BUG: unable to handle kernel paging request at 00007f7c64546000 [ 33.662554] IP: 0x7f7c64546000 ...
It should only take a little more work to leave the userspace page tables entirely unmapped while in kernel mode, and only map them in during
copy_from_user() as ARM already does with
CONFIG_CPU_SW_DOMAIN_PAN on arm32).
© 2018, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
Is KPTI something that you still see being used once Meltdown gets a hardware/microcode fix on future CPUs?
In other words, was KPTI/KAISER something you felt was necessary even before you guys discovered Meltdown?
Comment by ZZ — January 6, 2018 @ 4:21 pm
I’m more interested in unmapping userspace while in kernel (PTI is the reverse of this), but yeah, unmapping the kernel while in userspace kills a bunch of other side-channel attacks, so I would personally continue to use it even on “fixed hardware”.
Hello. Mr Cook I would like to ask a questions about PTI for ix86/x86_32 architecture: are there any plans to backport this feature? I know, that Developers (OpenSUSE and so on) are working on this etc. (see 1.) So, if everything will be okay, ‘Kernel Page Table Isolation’ should be available on 32. bit systems also, right?
Thanks, best regards.
Comment by kurdt — March 4, 2018 @ 11:08 am
Aggregate valuable and interesting links.
Joyk means Joy of geeK