scottconstable wrote:

This PR is intended to improve security for X86 kernels, as the title suggests. 
I think that we can and should incorporate feedback from the other 
participants, several of whom have recommended that this new behavior should be 
explicitly enabled with a flag, rather than implicitly enabled by examining the 
target triple. So, for example, I could update the PR to introduce a new flag 
such as `-fsanitize-cfi-icall-experimental-arity-x86`. If the community would 
like to adopt a similar approach that is tuned to benefit Arm64 kernels, then 
that approach could be enabled with a different flag.

Flag-based enabling would also help to address the concerns about compiler 
compatibility. For instance, if an x86 kernel is being built with both C and 
Rust code, then Kconfig could check whether the local clang and rustc compilers 
support the KCFI arity enhancement; if one or the other does not support KCFI 
arity then Kconfig would fall back to the default 32-bit hash.

@rcvalle I don't see any evidence that this approach will require a plethora of 
implementations for different arch/ABI combinations. As far as I am aware, the 
vast majority of x86-64 Linux kernel code (including eBPF code) uses the 
standard ABI. Even if some kernel code does not conform to the standard ABI, 
this should not break compatibility with the arity enhancement because the 
arity enhancement's implementation derives the arity tag from the function 
type, not from the ABI. Hence, a valid function call that uses a non-standard 
ABI would still experience a matching KCFI type ID at both the call site and 
the call target. The downside is that call sites/targets with a non-standard 
ABI might be tagged with an inaccurate arity, which could matter if the 
function type's 29-bit hash collides with another function type's 29-bit hash, 
and that other function's arity tag is the same but the two functions' actual 
arities differ. IMO this seems very unlikely.

https://github.com/llvm/llvm-project/pull/117121
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to