Re: [PATCH bpf-next v10 1/3] cfi: add C CFI type macro
From: Will Deacon <will@kernel.org>
Date: 2025-07-18 11:33:20
Also in:
bpf, lkml
On Tue, Jul 15, 2025 at 10:57:35PM +0000, Sami Tolvanen wrote:
From: Mark Rutland <mark.rutland@arm.com> Currently x86 and riscv open-code 4 instances of the same logic to define a u32 variable with the KCFI typeid of a given function. Replace the duplicate logic with a common macro. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Co-developed-by: Maxwell Bland <redacted> Signed-off-by: Maxwell Bland <redacted> Co-developed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Tested-by: Dao Huang <redacted> --- arch/riscv/kernel/cfi.c | 35 +++-------------------------------- arch/x86/kernel/alternative.c | 31 +++---------------------------- include/linux/cfi_types.h | 23 +++++++++++++++++++++++ 3 files changed, 29 insertions(+), 60 deletions(-)
[...]
quoted hunk ↗ jump to hunk
diff --git a/include/linux/cfi_types.h b/include/linux/cfi_types.h index 6b8713675765..e5567c0fd0b3 100644 --- a/include/linux/cfi_types.h +++ b/include/linux/cfi_types.h@@ -41,5 +41,28 @@ SYM_TYPED_START(name, SYM_L_GLOBAL, SYM_A_ALIGN) #endif +#else /* __ASSEMBLY__ */ + +#ifdef CONFIG_CFI_CLANG +#define DEFINE_CFI_TYPE(name, func) \ + /* \ + * Force a reference to the function so the compiler generates \ + * __kcfi_typeid_<func>. \ + */ \ + __ADDRESSABLE(func); \ + /* u32 name __ro_after_init = __kcfi_typeid_<func> */ \ + extern u32 name; \ + asm ( \ + " .pushsection .data..ro_after_init,\"aw\",@progbits \n" \ + " .type " #name ",@object \n" \ + " .globl " #name " \n" \ + " .p2align 2, 0x0 \n" \ + #name ": \n" \ + " .4byte __kcfi_typeid_" #func " \n" \ + " .size " #name ", 4 \n" \ + " .popsection \n" \ + ); +#endif
This looks good to me. I was initially a bit worried about the portability of the '.4byte' directive, but it seems that cfi_types.h is already using that for the __CFI_TYPE() macro so I'm assuming it's not an issue. In which case: Acked-by: Will Deacon <will@kernel.org> Thanks for cleaning it up. Will