Re: [PATCH v2 0/6] s390: Add kCFI support

[Nathan Chancellor]

On Mon, Jul 27, 2026 at 04:05:07PM +0200, Heiko Carstens wrote:
> v2:
> - Select ARCH_USES_CFI_GENERIC_LLVM_PASS [Nathan Chancellor]
> - Add CONFIG_FUNCTION_GRAPH_TRACER guard to ftrace stub [bot+bpf-ci]
> - Add additional CFI offset adjustments to bpf code [sashiko-bot]
> - Move bpf patch before ARCH_SUPPORTS_CFI is selected, since there are
>   functions with missing __bpfcall atttribute [sashiko-bot]
> 
> v1:
> Add s390 kCFI support using the generic support provided by clang.
> This comes with a couple of limitations:
> 
> The generic kCFI implementation does not generate a .kcfi_traps section,
> nor is a special instruction used in case a checksum mismatch is detected.
> 
> This means in case of a checksum mismatch the kernel just crashes.
> It should be quite easy to tell by the surrounding code that a crash
> happened because of a checksum mismatch.
> 
> If clang and/or gcc provide a .kcfi_traps section it will be possible to
> print proper CFI messages instead of just crashing the kernel (enable
> ARCH_USES_CFI_TRAPS).
> 
> In addition this also means that CFI_PERMISSIVE does not work. Even if the
> option is selected the kernel will crash in case of a checksum mismatch.
> 
> However it seems to be acceptable to enable kCFI support to the kernel now
> even if it is not perfect. Later s390 specific clang and gcc extensions are
> required to improve this.

Yes, getting coverage over s390 specific code and drivers is worthwhile,
even if there is no architecture specific expansion available yet, since
most problems should be visible with either implementation. Getting that
sooner rather than later would be nice to avoid the panic when a CFI
check fails and make debugging easier but we will take what we can get.

I tested clang-18 and clang-23 with defconfig + CFI, which both properly
fails the CFI_FORWARD_PROTO LKDTM test. I built allmodconfig (which now
includes CFI=y) with both compilers, which showed no issues.

Tested-by: Nathan Chancellor <nathan@xxxxxxxxxx>

-- 
Cheers,
Nathan