[all-commits] [llvm/llvm-project] e22348: [X86] Extend kCFI with a 3-bit arity indicator (#1...

[Scott Constable via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e223485c9b38a5579991b8cebb6a200153eee245
      https://github.com/llvm/llvm-project/commit/e223485c9b38a5579991b8cebb6a200153eee245
  Author: Scott Constable <scott.d.constable at intel.com>
  Date:   2025-02-06 (Thu, 06 Feb 2025)

  Changed paths:
    M clang/docs/ControlFlowIntegrity.rst
    M clang/docs/UsersManual.rst
    M clang/include/clang/Basic/CodeGenOptions.def
    M clang/include/clang/Basic/DiagnosticDriverKinds.td
    M clang/include/clang/Basic/Features.def
    M clang/include/clang/Driver/Options.td
    M clang/include/clang/Driver/SanitizerArgs.h
    M clang/lib/CodeGen/CodeGenModule.cpp
    M clang/lib/Driver/SanitizerArgs.cpp
    A clang/test/CodeGen/kcfi-arity.c
    M llvm/lib/Target/X86/X86AsmPrinter.cpp
    A llvm/test/CodeGen/X86/kcfi-arity.ll

  Log Message:
  -----------
  [X86] Extend kCFI with a 3-bit arity indicator (#121070)

Kernel Control Flow Integrity (kCFI) is a feature that hardens indirect
calls by comparing a 32-bit hash of the function pointer's type against
a hash of the target function's type. If the hashes do not match, the
kernel may panic (or log the hash check failure, depending on the
kernel's configuration). These hashes are computed at compile time by
applying the xxHash64 algorithm to each mangled canonical function (or
function pointer) type, then truncating the result to 32 bits. This hash
is written into each indirect-callable function header by encoding it as
the 32-bit immediate operand to a `MOVri` instruction, e.g.:
```
__cfi_foo:
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	movl	$199571451, %eax                # hash of foo's type = 0xBE537FB
foo:
        ...
```

This PR extends x86-based kCFI with a 3-bit arity indicator encoded in
the `MOVri` instruction's register (reg) field as follows:

| Arity Indicator | Description | Encoding in reg field |
| --------------- | --------------- | --------------- |
| 0 | 0 parameters | EAX |
| 1 | 1 parameter in RDI | ECX |
| 2 | 2 parameters in RDI and RSI | EDX |
| 3 | 3 parameters in RDI, RSI, and RDX | EBX |
| 4 | 4 parameters in RDI, RSI, RDX, and RCX | ESP |
| 5 | 5 parameters in RDI, RSI, RDX, RCX, and R8 | EBP |
| 6 | 6 parameters in RDI, RSI, RDX, RCX, R8, and R9 | ESI |
| 7 | At least one parameter may be passed on the stack | EDI |

For example, if `foo` takes 3 register arguments and no stack arguments
then the `MOVri` instruction in its kCFI header would instead be written
as:
```
	movl	$199571451, %ebx                # hash of foo's type = 0xBE537FB
```

This PR will benefit other CFI approaches that build on kCFI, such as
FineIBT. For example, this proposed enhancement to FineIBT must be able
to infer (at kernel init time) which registers are live at an indirect
call target: https://lkml.org/lkml/2024/9/27/982. If the arity bits are
available in the kCFI function header, then this information is trivial
to infer.

Note that there is another existing PR proposal that includes the 3-bit
arity within the existing 32-bit immediate field, which introduces
different security properties:
https://github.com/llvm/llvm-project/pull/117121.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications