On 29/09/2022 23:28, Rick Edgecombe wrote: > diff --git a/Documentation/x86/cet.rst b/Documentation/x86/cet.rst > new file mode 100644 > index 000000000000..4a0dfb6830f9 > --- /dev/null > +++ b/Documentation/x86/cet.rst > @@ -0,0 +1,140 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +========================================= > +Control-flow Enforcement Technology (CET) > +========================================= > + > +Overview > +======== > + > +Control-flow Enforcement Technology (CET) is term referring to several > +related x86 processor features that provides protection against control > +flow hijacking attacks. The HW feature itself can be set up to protect > +both applications and the kernel. Only user-mode protection is implemented > +in the 64-bit kernel. > + > +CET introduces Shadow Stack and Indirect Branch Tracking. Shadow stack is > +a secondary stack allocated from memory and cannot be directly modified by > +applications. When executing a CALL instruction, the processor pushes the > +return address to both the normal stack and the shadow stack. Upon > +function return, the processor pops the shadow stack copy and compares it > +to the normal stack copy. If the two differ, the processor raises a > +control-protection fault. Indirect branch tracking verifies indirect > +CALL/JMP targets are intended as marked by the compiler with 'ENDBR' > +opcodes. Not all CPU's have both Shadow Stack and Indirect Branch Tracking > +and only Shadow Stack is currently supported in the kernel. This paragraph is stale, isn't it? AIUI, by the end of this series, what is supported is in-kernel self-protection using CET-IBT, and userspace shadow stacks. It is probably worth keeping the implementation-agnostic bits separate from the "what is currently supported" matrix. I'm not certain if its worth splitting into cet.rst, cet-kernel.rst and cet-user.rst at this point, but it's something to consider. > +The Kconfig options is X86_SHADOW_STACK, and it can be disabled with > +the kernel parameter clearcpuid, like this: "clearcpuid=shstk". What about namespacing? For the CPUID features themselves, yes they're shstk and ibt. But for the Kconfig options, the user and kernel implementations are wildly different for both shstk and ibt. Are they going to want to share the same Kconfig option from the getgo? Independent of the Kconfig symbol, user and kernel have separate enablement criteria. e.g. kernel shstk is likely going to be dependent on the FRED feature, and simply looking at `shstk` in /proc/cpuinfo doesn't necessarily tell you all you want to know. > + > +To build a CET-enabled kernel, Binutils v2.31 and GCC v8.1 or LLVM v10.0.1 What are the other dependences here? In principle shstk only needs assembler support for the new instructions, and that's Binutils 2.29 / LLVM 6 from my notes. It's IBT which needs compiler support (and then, even only kernel IBT), and that work is already done. > +or later are required. To build a CET-enabled application, GLIBC v2.28 or > +later is also required. > + > +At run time, /proc/cpuinfo shows CET features if the processor supports > +CET. Probably helpful to state what these are. > + > +Application Enabling > +==================== > + > +An application's CET capability is marked in its ELF header and can be Technically its in an ELF note, not the ELF header. ~Andrew
