-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KCFI: Add KCFI arity indicator support #138368
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,61 @@ | ||
// Verifies that KCFI arity indicator is emitted. | ||
// | ||
//@ add-core-stubs | ||
//@ revisions: x86_64 | ||
//@ assembly-output: emit-asm | ||
//@[x86_64] compile-flags: --target x86_64-unknown-linux-gnu -C llvm-args=-x86-asm-syntax=intel -Ctarget-feature=-crt-static -Zsanitizer=kcfi -Zsanitizer-kcfi-arity -Copt-level=0 | ||
//@[x86_64] needs-llvm-components: x86 | ||
//@ min-llvm-version: 20.1.0 | ||
|
||
#![crate_type = "lib"] | ||
|
||
pub fn add_one(x: i32) -> i32 { | ||
// CHECK-LABEL: __cfi__{{.*}}7add_one{{.*}}: | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: mov eax, 2628068948 | ||
x + 1 | ||
} | ||
|
||
pub fn add_two(x: i32, _y: i32) -> i32 { | ||
// CHECK-LABEL: __cfi__{{.*}}7add_two{{.*}}: | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: mov eax, 2505940310 | ||
x + 2 | ||
} | ||
|
||
pub fn do_twice(f: fn(i32) -> i32, arg: i32) -> i32 { | ||
// CHECK-LABEL: __cfi__{{.*}}8do_twice{{.*}}: | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: nop | ||
// CHECK-NEXT: mov eax, 653723426 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @ojeda @scottconstable I think I've it mostly done, but I suspect this test isn't right. If I understood it correctly, according to the table in llvm/llvm-project#121070 (comment), this operation should use EDX(?) because callers would pass two parameters before calling (Note that this isn't actually arity that is being indicated. This function's arity is three (3): two parameters, and a return value.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm... I am not sure what you mean. Arity is the number of parameters, without the return value, so it should use 2, thus it should use EDX. From a quick test with Clang, that is the case. I also get the same result if I take Are you seeing a different result? By the way, why don't we test a simpler function, e.g. one that just sums two numbers? i.e. the intention here is to notice the difference between the disabled and enabled cases. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, the return value is not included. You're right. What I was noting there, if I understood it correctly, is that "arity" is being defined there in that PR and table at the ABI level with certain things being excluded such as parameters passed on the stack, which would cause it the "arity" defined there to diverge from the actual arity of a function, but that is not relevant here, I was just pointing it out again as I did when it was initially proposed. Let me try a simpler pair of functions and get back to you. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm still getting EAX used with a new test using a simpler pair of functions with different arity. My LLVM version is
Which should include it, right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I don't think so, upstream LLVM 20.1.0 does not contain it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So I wanted this one landed in nightly mostly so that the kernel people could test it easily by downloading the nightly, but if I also don't want to give too much trouble to I will probably build a test toolchain for Peter with this PR applied for the time being. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. SG! Let me know if there is anything I can help with in the meantime. If needed, I can also remove the checks and test and get it merged, and add these later. Just let me know! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If you look at the llvm-main tag, you can see that we regularly condition things things to not-yet-released LLVM (e.g. LLVM 21 in this case) so that they start working as soon as released, or if There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Will take a look. Thank you! Should we condition this on LLVM 21? Or will there be any minor version release that will have this feature? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would condition this on LLVM 21 - My understanding of current LLVM version numbers are:
So I'd just condition on the major version, e.g. >= 21.0, so that dev versions start working immediately. There will be LLVM builds which report 21.0 which do not have support for this, but people using unreleased LLVMs usually know they need to be careful of this kind of thing, and there's not much we can do to help them. This also matches how we treat the |
||
f(arg) + f(arg) | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,19 @@ | ||
// Verifies that "kcfi-arity" module flag is added. | ||
// | ||
//@ add-core-stubs | ||
//@ revisions: x86_64 | ||
//@ [x86_64] compile-flags: --target x86_64-unknown-none | ||
//@ [x86_64] needs-llvm-components: x86 | ||
//@ compile-flags: -Ctarget-feature=-crt-static -Zsanitizer=kcfi -Zsanitizer-kcfi-arity | ||
//@ min-llvm-version: 20.1.0 | ||
|
||
#![feature(no_core, lang_items)] | ||
#![crate_type = "lib"] | ||
#![no_core] | ||
|
||
extern crate minicore; | ||
use minicore::*; | ||
|
||
pub fn foo() {} | ||
|
||
// CHECK: !{{[0-9]+}} = !{i32 4, !"kcfi-arity", i32 1} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
// Verifies that `-Zsanitizer-kcfi-arity` requires `-Zsanitizer=kcfi`. | ||
// | ||
//@ needs-sanitizer-kcfi | ||
//@ compile-flags: -Cno-prepopulate-passes -Ctarget-feature=-crt-static -Zsanitizer-kcfi-arity | ||
//@ min-llvm-version: 20.1.0 | ||
|
||
#![feature(no_core)] | ||
#![no_core] | ||
#![no_main] |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
error: `-Zsanitizer-kcfi-arity` requires `-Zsanitizer=kcfi` | ||
|
||
error: aborting due to 1 previous error | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not the case -- there is no tag yet in upstream LLVM that contains the feature, sadly.