LWN: Comments on "Control-flow integrity for the kernel"

Control-flow integrity for the kernel

luto — Thu, 23 Jan 2020 23:59:24 +0000

There are two mechanisms.

The EPT one takes advantage of the fact that EPT allows a host-physical-to-guest-physical mapping to be execute only. By duplicating the entire guest physical space, a hypervisor can effectively repurpose a physical address bit in the guest pagetables as XO. The only real snags are that an attempt to read XO memory results in an EPT violation instead of a page fault, resulting in some trickery, and that this technique doesn’t work at all on bare metal. Patches for this exist. I don’t recall whether they’re applied yet.

The other technique is that, if user code doesn’t ask for a specific protection key on a PKRU-capable system, the kernel will use a special key for XO memory and will program the PKRU register to disallow reads. This is user-visible and awkward, but it works.

Control-flow integrity for the kernel

alejluther — Thu, 23 Jan 2020 22:00:13 +0000

Thanks for the info.

I have not found detailed information about this Intel mechanism, just an old email from 2015 but referring to a future functionality. Is that work what you refer to?

If it was mentioned "it is coming", maybe it is something re-started by Intel or ARM improving the current support. Good to know anyway.

Control-flow integrity for the kernel

luto — Thu, 23 Jan 2020 18:59:28 +0000

ARM *did* support XO for user mode, but it was reverted because it defeated other hardening features. I don’t know about kernel.

x86 XO has prototype patches that require hypervisor assistance. If you’re lucky enough to have PKRU hardware (thanks, Intel, for coming up with all these server only features), then XO is emulated for user mode using PKRU.

Control-flow integrity for the kernel

khim — Thu, 23 Jan 2020 17:28:49 +0000

Funny that you have said "Is this Intel processors or maybe ARM as well?"

Intel is legacy novadays. ARM supports execute-only memory already (although not sure if it's ARM64 thingie or ARM32 works, too), even if software is not quite there. Not sure about Intel.

Control-flow integrity for the kernel

kees — Wed, 22 Jan 2020 09:47:12 +0000

I didn't cover the DSO support in Clang's CFI implementation just because things were already pretty complex and I wasn't going to have time to cover everything. The short version is: when a function is not found in the jump table in the main kernel text, it is redirected to a __cfi_check() function exported by modules, and the jump tables are effectively "extended" for each function prototype bucket. More details are here under the "Shared library support" heading.

Control-flow integrity for the kernel

alejluther — Wed, 22 Jan 2020 09:04:00 +0000

Can anyone share more information about the executable-pages only functionality which as mentioned is coming? Is this Intel processors or maybe ARM as well?

This is going to be a main hit against memory disclosure then exploit attacks. There will be maybe other information leaks like Meltdown and Spectre, but as far as I know they are painfully slow for collecting the data leak so preemptive defences can work then.

Control-flow integrity for the kernel

Aaron1011 — Wed, 22 Jan 2020 02:32:02 +0000

How does this interact with kernel modules?