run-make: Delete cat-and-grep-sanity-check and restrict branch-protection-check-IBT to stable#129156
Closed
Oneirical wants to merge 2 commits intorust-lang:masterfrom
Closed
run-make: Delete cat-and-grep-sanity-check and restrict branch-protection-check-IBT to stable#129156Oneirical wants to merge 2 commits intorust-lang:masterfrom
cat-and-grep-sanity-check and restrict branch-protection-check-IBT to stable#129156Oneirical wants to merge 2 commits intorust-lang:masterfrom
Conversation
Collaborator
rustbot
added
A-run-make
Collaborator
|
This PR modifies cc @jieyouxu |
Member
|
@bors delegate+ (try jobs) |
Collaborator
|
✌️ @Oneirical, you can now approve this pull request! If @jieyouxu told you to " |
Contributor
Author
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 16, 2024
run-make: Delete `cat-and-grep-sanity-check` and restrict `branch-protection-check-IBT` to stable Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html). First, this PR deletes the now useless `cat-and-grep-sanity-check` test. Second, it revisits the `branch-protection-check-IBT` test, which was disabled due to a nonsensical `llvm_components` check. rust-lang#126720 states that the test does work on stable rustc, so let's check this: added `//@ only-stable`. If this works, some of the FIXME and commented-out lines will need cleanup before merging. Please try: try-job: x86_64-gnu-stable
Collaborator
This comment has been minimized.
This comment has been minimized.
Oneirical
force-pushed
the
final-curtest-call
branch
from
41cd029 to
d85d292
Compare
rustbot
added
A-testsuite
Contributor
Author
|
@bors try- (feature request: this should be called bors give up) |
Contributor
Author
|
@bors try |
Collaborator
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 16, 2024
run-make: Delete `cat-and-grep-sanity-check` and restrict `branch-protection-check-IBT` to stable Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html). First, this PR deletes the now useless `cat-and-grep-sanity-check` test. Second, it revisits the `branch-protection-check-IBT` test, which was disabled due to a nonsensical `llvm_components` check. rust-lang#126720 states that the test does work on stable rustc, so let's check this: added `//@ only-stable`. If this works, some of the FIXME and commented-out lines will need cleanup before merging. Please try: try-job: x86_64-gnu-stable
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
fbstj
reviewed
Aug 16, 2024
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Collaborator
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-author
jieyouxu
reviewed
Aug 21, 2024
Member
jieyouxu
left a comment
jieyouxu
left a comment
There was a problem hiding this comment.
Hm. I'll need to find PG-exploit-mitigations experts to help us take a look. This seems weird.
| // python3 x.py test --target x86_64-unknown-linux-gnu tests/run-make/branch-protection-check-IBT/ | ||
|
|
||
| //@ only-x86_64 | ||
| //@ only-stable |
Member
There was a problem hiding this comment.
Problem: this can't be correct, it's been in stable since forever, and I don't see any changes that would cause this to not be emitted (yet).
| //@ only-stable | ||
|
|
||
| //@ ignore-test | ||
| // FIXME(jieyouxu): see the FIXME in the Makefile |
|
|
||
| all: | ||
| ifeq ($(filter x86,$(LLVM_COMPONENTS)),x86_64) | ||
| $(RUSTC) --target x86_64-unknown-linux-gnu -Z cf-protection=branch -L$(TMPDIR) -C link-args='-nostartfiles' -C save-temps ./main.rs -o $(TMPDIR)/rsmain |
Member
There was a problem hiding this comment.
Discussion: I used cross to try to reproduce this, and lo-and-behold, there is no .note.gnu.property:
PS E:\Repos\test\huh> cat .\target\x86_64-unknown-linux-gnu\debug\.fingerprint\huh-1e1959310e6cde68\bin-huh.json
{"rustc":11041252367277408880,"features":"[]","declared_features":"[]","target":3507701825157409998,"profile":6929766844333714335,"path":10602529704205407992,"deps":[],"local":[{"CheckDepInfo":{"dep_info":"x86_64-unknown-linux-gnu/debug/.fingerprint/huh-1e1959310e6cde68/dep-bin-huh"}}],"rustflags":["-Z","cf-protection=branch","-C","link-args=-nostartfiles"],"metadata":7797948686568424061,"config":2202906307356721367,"compile_kind":9018714775688763800}
PS E:\Repos\test\huh> readelf -n .\target\x86_64-unknown-linux-gnu\debug\huh
Displaying notes found in: .note.gnu.build-id
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: fa9d90e0ef28addf979dfd4645b35a4a06308327
PS E:\Repos\test\huh>
there is .note.gnu.build-id. I'm suspecting maybe the Intel CET landscape changed to no longer require this note...?
Contributor
Author
There was a problem hiding this comment.
Rejyr got to display the gnu property note by using the following commands:
$ rustc +stable main.rs -o main
$ llvm-readobj --elf-output-style=GNU -nW main
Could this have something to do with --elf-output-style=GNU? Or perhaps with the extra flags being passed to rustc?
Member
There was a problem hiding this comment.
Ah good point. I need to double-check this with the people who knows about Intel IBT (not to be confused with Arm's BTI, also this is -Z cf-protection=branch, not to be confused with -Z branch-protection). Thanks for the info.
-Z cf-protection: Tracking Issue for control-flow enforcement technology (CET) #93754-Z branch-protection: Tracking Issue for stabilisation of-Z branch-protection#113369
Remark (for myself):
- Initial issue: Synthetic object files disable control flow protection features #103001
- Initial PR: Add GNU Property Note #110304
Relevant docs:
Arm
BTI: Branch Target Identification
Docs: https://developer.arm.com/documentation/102433/latest/Applying-these-techniques-to-real-code
Intel x86_64
IBT: Indirect Branch Tracking
Docs: https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/12th-generation-intel-core-processors-datasheet-volume-1-of-2/006/indirect-branch-tracking/
Member
There was a problem hiding this comment.
Could this have something to do with
--elf-output-style=GNU?
That seems a bit weird, because in my case I was compiling on a x86_64 host for a x86_64 target, so surely --elf-output-style can't be arm... right?
Member
There was a problem hiding this comment.
no repro in a docker container w/ x86_64-gnu either.
Comment on lines
-14
to
+16
| let llvm_components = env_var("LLVM_COMPONENTS"); | ||
| if !format!(" {llvm_components} ").contains(" x86 ") { | ||
| return; | ||
| } | ||
| // if !llvm_components_contain("x86") { | ||
| // panic!(); | ||
| // } |
Member
There was a problem hiding this comment.
Discussion (self-remark mostly): it's not entirely clear to me why we need to check for llvm-components.
EDIT: because if we want to run target-specific codegen, it will need the llvm component. Right.
jieyouxu
added
S-waiting-on-review
Member
|
cc @bjorn3 do you have any idea if AFAICT (at least on nightly/master), on a $ rustc \
--target=x86_64-linux-unknown-gnu \
-Z cf-protection=branch \
-C link-args='-nostartfiles' \
hello_world.rs \
-o hello_world
$ llvm-readelf -nW hello_worldonly has build-id, not Update: may need |
Member
|
As nikic suggested, I was able to repro the note via $ RUSTFLAGS="-Z cf-protection=branch" cargo +nightly build -Z build-std --target=x86_64-unknown-linux-gnuso we probably want to use bootstrap cargo like in some other tests (yes I know this will require internet connection and is probably not ideal). |
jieyouxu
added
S-waiting-on-author
Member
Not all that familiar with this, but I would IBT to only be enabled for the process if |
alex-semenyuk
added
S-waiting-on-author
Collaborator
|
☔ The latest upstream changes (presumably #131387) made this pull request unmergeable. Please resolve the merge conflicts. |
Member
|
@Oneirical any updates on this? thanks |
Member
|
@rustbot review (I need to look at it again) |
rustbot
added
S-waiting-on-review
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 25, 2024
…eck-IBT, r=<try> Migrate `branch-protection-check-IBT` to rmake.rs - The Makefile version *never* ran because of Makefile syntax confusion because `ifeq ($(filter x86,$(LLVM_COMPONENTS)),x86_64)` [compares `x86` to `x86_64`, which always evaluates to false](rust-lang#126720 (comment)). - The test would've always failed because precompiled std is not built with `-Z cf-protection=branch`, but linkers require all input object files to indicate IBT support in order to enable IBT for the executable, which is not the case for std. - Thus, the test input file is instead changed to a `no_std` program. The GNU property note was added by rust-lang#110304 in order to address rust-lang#103001. Partially supersedes rust-lang#129156. The rmake.rs port was initially authored by `@Rejyr` in rust-lang#126720. This PR is co-authored with `@Oneirical` and `@Rejyr.` r? `@bjorn3` or reroll try-job: x86_64-msvc try-job: x86_64-apple
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 25, 2024
…eck-IBT, r=<try> Migrate `branch-protection-check-IBT` to rmake.rs - The Makefile version *never* ran because of Makefile syntax confusion because `ifeq ($(filter x86,$(LLVM_COMPONENTS)),x86_64)` [compares `x86` to `x86_64`, which always evaluates to false](rust-lang#126720 (comment)). - The test would've always failed because precompiled std is not built with `-Z cf-protection=branch`, but linkers require all input object files to indicate IBT support in order to enable IBT for the executable, which is not the case for std. - Thus, the test input file is instead changed to a `no_std` program. The GNU property note was added by rust-lang#110304 in order to address rust-lang#103001. Partially supersedes rust-lang#129156. The rmake.rs port was initially authored by `@Rejyr` in rust-lang#126720. This PR is co-authored with `@Oneirical` and `@Rejyr.` r? `@bjorn3` or reroll try-job: x86_64-msvc try-job: x86_64-apple-1 try-job: x86_64-apple-2
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 26, 2024
…eck-IBT, r=<try> Migrate `branch-protection-check-IBT` to rmake.rs - The Makefile version *never* ran because of Makefile syntax confusion because `ifeq ($(filter x86,$(LLVM_COMPONENTS)),x86_64)` [compares `x86` to `x86_64`, which always evaluates to false](rust-lang#126720 (comment)). - The test would've always failed because precompiled std is not built with `-Z cf-protection=branch`, but linkers require all input object files to indicate IBT support in order to enable IBT for the executable, which is not the case for std. - Thus, the test input file is instead changed to a `no_std` program. - Ignore cross-compile for now, because that will require us to build `core` for the cross-compile target (something like `minicore` will not suffice because we need to reach and go past the linking stage). The GNU property note was added by rust-lang#110304 in order to address rust-lang#103001. Partially supersedes rust-lang#129156. The rmake.rs port was initially authored by `@Rejyr` in rust-lang#126720. This PR is co-authored with `@Oneirical` and `@Rejyr.` r? `@bjorn3` or reroll try-job: x86_64-msvc try-job: x86_64-apple-1 try-job: x86_64-apple-2
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 26, 2024
…eck-IBT, r=<try> Migrate `branch-protection-check-IBT` to rmake.rs - The Makefile version *never* ran because of Makefile syntax confusion because `ifeq ($(filter x86,$(LLVM_COMPONENTS)),x86_64)` [compares `x86` to `x86_64`, which always evaluates to false](rust-lang#126720 (comment)). - The test would've always failed because precompiled std is not built with `-Z cf-protection=branch`, but linkers require all input object files to indicate IBT support in order to enable IBT for the executable, which is not the case for std. - Thus, the test input file is instead changed to a `no_std` program. - Only specifically `x86_64-unknown-linux-gnu` for now. The GNU property note was added by rust-lang#110304 in order to address rust-lang#103001. Partially supersedes rust-lang#129156. The rmake.rs port was initially authored by `@Rejyr` in rust-lang#126720. This PR is co-authored with `@Oneirical` and `@Rejyr.` r? `@bjorn3` or reroll try-job: x86_64-mingw-1 try-job: x86_64-mingw-2 try-job: x86_64-msvc try-job: x86_64-apple-1 try-job: x86_64-apple-2
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Dec 28, 2024
…check-IBT, r=lqd Migrate `branch-protection-check-IBT` to rmake.rs - The Makefile version *never* ran because of Makefile syntax confusion because `ifeq ($(filter x86,$(LLVM_COMPONENTS)),x86_64)` [compares `x86` to `x86_64`, which always evaluates to false](rust-lang#126720 (comment)). - The test would've always failed because precompiled std is not built with `-Z cf-protection=branch`, but linkers require all input object files to indicate IBT support in order to enable IBT for the executable, which is not the case for std. - Thus, the test input file is instead changed to a `no_std` program. - The test is currently limited to only `x86_64-unknown-linux-gnu` host, there are various other problems when the test is cross-compiled that I didn't want to fix atm, and is left as an exercise for the `-Z cf-protection` implementers. The GNU property note was added by rust-lang#110304 in order to address rust-lang#103001. Partially supersedes rust-lang#129156. The rmake.rs port was initially authored by `@Rejyr` in rust-lang#126720. This PR is co-authored with `@Oneirical` and `@Rejyr.` r? `@bjorn3` or reroll try-job: x86_64-mingw-1 try-job: x86_64-mingw-2 try-job: x86_64-msvc try-job: x86_64-apple-1 try-job: x86_64-apple-2
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 28, 2024
Rollup merge of rust-lang#134760 - jieyouxu:enable-branch-protection-check-IBT, r=lqd Migrate `branch-protection-check-IBT` to rmake.rs - The Makefile version *never* ran because of Makefile syntax confusion because `ifeq ($(filter x86,$(LLVM_COMPONENTS)),x86_64)` [compares `x86` to `x86_64`, which always evaluates to false](rust-lang#126720 (comment)). - The test would've always failed because precompiled std is not built with `-Z cf-protection=branch`, but linkers require all input object files to indicate IBT support in order to enable IBT for the executable, which is not the case for std. - Thus, the test input file is instead changed to a `no_std` program. - The test is currently limited to only `x86_64-unknown-linux-gnu` host, there are various other problems when the test is cross-compiled that I didn't want to fix atm, and is left as an exercise for the `-Z cf-protection` implementers. The GNU property note was added by rust-lang#110304 in order to address rust-lang#103001. Partially supersedes rust-lang#129156. The rmake.rs port was initially authored by `@Rejyr` in rust-lang#126720. This PR is co-authored with `@Oneirical` and `@Rejyr.` r? `@bjorn3` or reroll try-job: x86_64-mingw-1 try-job: x86_64-mingw-2 try-job: x86_64-msvc try-job: x86_64-apple-1 try-job: x86_64-apple-2
poliorcetics
pushed a commit
to poliorcetics/rust
that referenced
this pull request
Dec 28, 2024
…check-IBT, r=lqd Migrate `branch-protection-check-IBT` to rmake.rs - The Makefile version *never* ran because of Makefile syntax confusion because `ifeq ($(filter x86,$(LLVM_COMPONENTS)),x86_64)` [compares `x86` to `x86_64`, which always evaluates to false](rust-lang#126720 (comment)). - The test would've always failed because precompiled std is not built with `-Z cf-protection=branch`, but linkers require all input object files to indicate IBT support in order to enable IBT for the executable, which is not the case for std. - Thus, the test input file is instead changed to a `no_std` program. - The test is currently limited to only `x86_64-unknown-linux-gnu` host, there are various other problems when the test is cross-compiled that I didn't want to fix atm, and is left as an exercise for the `-Z cf-protection` implementers. The GNU property note was added by rust-lang#110304 in order to address rust-lang#103001. Partially supersedes rust-lang#129156. The rmake.rs port was initially authored by `@Rejyr` in rust-lang#126720. This PR is co-authored with `@Oneirical` and `@Rejyr.` r? `@bjorn3` or reroll try-job: x86_64-mingw-1 try-job: x86_64-mingw-2 try-job: x86_64-msvc try-job: x86_64-apple-1 try-job: x86_64-apple-2
Member
|
Superseded by #134760 with attribution, thanks for the PR! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #121876 and the associated Google Summer of Code project.
First, this PR deletes the now useless
cat-and-grep-sanity-checktest.Second, it revisits the
branch-protection-check-IBTtest, which was disabled due to a nonsensicalllvm_componentscheck. #126720 states that the test does work on stable rustc, so let's check this: added//@ only-stable.If this works, some of the FIXME and commented-out lines will need cleanup before merging.
Please try:
try-job: x86_64-gnu-stable