LWN: Comments on "Kernel support for hardware-based control-flow integrity"

Kernel support for hardware-based control-flow integrity

nix — Fri, 09 Sep 2022 19:59:08 +0000

The point isn't huge in the sense of performance cost: it's huge in the sense of complexity cost. This has needed a whole new mechanism in glibc ld.so to identify cases where shared libraries compiled without CET support are loaded at startup or via dlopen into a process which has CET support active: all you can do in that case is to fail the load (IIRC), reducing reliability unless you do a whole-distro rebuild with CET enabled and never run libraries obtained from any other source. Every single thing involving unusual patterns of control flow needed (often extremely tricky) modification. Some things (like setjmp) involve fixed-size structures baked into user programs: a perennial source of pain, but this made that pain a bit worse. And so on.

Kernel support for hardware-based control-flow integrity

jepsis — Fri, 09 Sep 2022 14:30:45 +0000

"But the cost of those shadow stack thingy is huge."

Not so huge. Many Android phones have these enabled. Chrome OS too. Enabling CFI is strongly recommended on Android devices.

Kernel support for hardware-based control-flow integrity

alkbyby — Tue, 09 Aug 2022 01:18:23 +0000

Well, because returns are much easier to make more robust. We don't just return to any call site but to exact call site that was used for this specific stack frame.

Compared to that forward edge stuff looks weak. And I'd argue, what is the point building feature that is immediately ~useless from the start.

But the cost of those shadow stack thingy is huge. It is not just debuggers and criu. Exception handling too. Various forms of longjmp (yes, AFAIR standard only allows to it to "skip" call frames, but in practice some folk have used it for more advanced means, and those will break). {make,swap}context and friends will break too, I think. And some people have built useful software around those too. Are we saying non-standard control flow now requires a syscall (in our still crazy times when syscall latency is sky-high, sadly)

Also I am curious how that works or doesn't work with dlopen-ed codes. If my initial set of modules (executable + .so-s) are compatible, but then I dlopen something legacy what happens ?

Kernel support for hardware-based control-flow integrity

tamiko — Tue, 12 Jul 2022 14:23:45 +0000

Threaded INTERCAL :-)

Kernel support for hardware-based control-flow integrity

scientes — Tue, 12 Jul 2022 02:09:13 +0000

There is a joke language with COME FROM, and if you have multiple of these attached to the same label it forks.

Kernel support for hardware-based control-flow integrity

Wol — Mon, 11 Jul 2022 16:50:23 +0000

What about the "RETURN TO" instruction?

Istr a couple of languages where you could return to a different label in the caller than the original call site ...

Cheers,
Wol

Kernel support for hardware-based control-flow integrity

Bigos — Mon, 11 Jul 2022 16:15:54 +0000

At least on architectures with fixed-size instructions (like arm64) a simpler solution would be to look back one instruction to check whether it is a call instruction. On x86-64 that would be trickier.

Still, that would only help checking whether the return destination is "a" call-site, not that it is "the" call-site that originated the call. Maybe that was not deemed useful enough? You could still return to the middle of any function, even though the return destination is restricted to call-sites.

Kernel support for hardware-based control-flow integrity

willy — Mon, 11 Jul 2022 15:58:14 +0000

There's no real difference between CALL and RET. Both change the IP to a different location and both need the same protection. Why did the HW vendors feel the need to invent different mechanisms instead of making every CALL insn be followed by an ENDBR insn so they could verify a RET was returning to _a_ callsite?