Messages in this thread | | | From | "Edgecombe, Rick P" <> | Subject | Re: CET shadow stack app compatibility | Date | Tue, 15 Nov 2022 17:04:40 +0000 |
| |
On Tue, 2022-11-15 at 10:43 +0100, Peter Zijlstra wrote: > 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.
The only other place in the kernel where it has to be that way is the "control protection" fault handler.
I agree it's confusing, but when you talk about "shadow stacks", a lot of people don't connect it to the HW feature. Where as they have heard of CET. So for contexts like this, I thought it was useful to jog memories. I could put more distance between it... "x86 shadow stacks (you may have heard of CET)".
> > ELF bits should not, must not, be called CET. API, not CET, Compiler > features, also not CET.
So the arch_prctl()s can't be shared between shadow stack and IBT? They don't have to be, but this is a new thing after a fair amount of earlier discussion.
> > (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).
| |