Re: CET shadow stack app compatibility

[Peter Zijlstra <peterz@infradead.org>]

Let me hijack this and go off on a tangent..

On Mon, Nov 14, 2022 at 11:15:44PM +0000, Edgecombe, Rick P wrote:

> The breakage derives from how the decision is made on whether to enable
> shadow stack enforcement. Glibc will do this by checking a bit in the
> elf header of the binary. It then tells the kernel to turn CET on via a
> separate kernel API. But instead of this elf bit being selected by
> application developers, it was mostly applied in various automated ways
> (mostly default on) by distro builds for years. This huge amount of
> untested enablement has not generated any visible issues for users yet,
> because without kernel support the presence of this bit has not
> generated any actual CET enforcement.

CET is two things, ideally we're fully eradicate the term CET, never
again mention CET, ever. Whoever at Intel decided to push that term has
created so much confusion it's not funny :/

The feature at hand here is backward edge control flow -- or shadow
stacks (the means to implement this). Be explicit about this, do *NOT*
use CET ever again.

The other thing CET has is forward edge control flow -- or indirect
branch tracking, this is a completely different and independent feature
and not advertised or implemented here.

These things are obviously related, but since they're two independent
features there's the endless confusion as to which is actually meant.

(go (re)watch the last plumbers conf talks on the subject -- there's
always someone who gets is wrong)

The only things that should have CET in their name are the CR4 bit and
the two MSRs, nothing more.

ELF bits should not, must not, be called CET. API, not CET, Compiler
features, also not CET.

(and I know it's too late to eradicate some of it, but please, at least
make sure the kernel doesn't propagate this nonsense).