Re: [PATCH v2 01/39] Documentation/x86: Add CET description

[Andrew Cooper]

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