update fortanix tests #144395

folkertdev · 2025-07-24T12:16:41Z

Firstly, as far as I can tell, no CI job actually runs any of the fortanix tests? Maybe I'm missing the job that runs these tests though?

In any case, the assembly tests now use minicore, meaning that they will run regardless of the host architecture (specifically, they will run during a standard PR CI build).

The run-make test is actually broken, and I'd propose to make it just cargo build rather than cargo run. We can have a separate test for actually running the program, if desired.

Also this test is subject to #128733, so I'd like to re-evaluate what parts of the C/C++ compilation are actually required or useful.

cc @jethrogb @raoulstrackx @aditijannu

r? @jieyouxu

rustbot · 2025-07-24T12:16:47Z

jieyouxu is currently at their maximum review capacity.
They may take a while to respond.

rustbot · 2025-07-24T12:16:49Z

This PR modifies run-make tests.

cc @jieyouxu

tests/assembly-llvm/x86_64-fortanix-unknown-sgx-lvi-generic-load.rs

folkertdev · 2025-07-24T12:18:57Z

tests/run-make/x86_64-fortanix-unknown-sgx-lvi/rmake.rs

-    // - C/C++ code compiled as part of Rust crates
-    // For those different kinds, we do have very small code examples that should be
-    // mitigated in some way. Mostly we check that ret instructions should no longer be present.
+    cargo().arg("-v").arg("run").arg("--target").arg(target()).current_dir("enclave").run();


Can this instead be cargo build? That means to run the test one would not need the whole fortanix toolchain setup.

Also, when I do make that change, this test actually fails. So, that again suggests this test does not actually run on CI. When this test was introduced in #77008, nothing is changed to CI to make it run, so unless that was added before I don't think this ever actually worked.

Yes cargo build should work just as good.

In order to mitigate LVI, all binary code needs to be mitigated. This test includes code generation for Rust code, inline assembly, global assembly and C/C++ code compiled as part of Rust crates. For the latter there need to be environment variables set:

CC_x86_64_fortanix_unknown_sgx=clang-11 \ CFLAGS_x86_64_fortanix_unknown_sgx="-D__ELF__ -isystem/usr/include/x86_64-linux-gnu -mlvi-hardening -mllvm -x86-experimental-lvi-inline-asm-hardening" \ CXX_x86_64_fortanix_unknown_sgx=clang++-11 \ CXXFLAGS_x86_64_fortanix_unknown_sgx="-D__ELF__ -isystem/usr/include/x86_64-linux-gnu -mlvi-hardening -mllvm -x86-experimental-lvi-inline-asm-hardening" \

we do that in src/ci/docker/host-x86_64/dist-various-2/Dockerfile. When testing this locally, you may not have this set.

So, it is my understanding that the dist- jobs do not actually run any tests. From https://rustc-dev-guide.rust-lang.org/tests/ci.html?highlight=try#ci-workflow:

Dist jobs build a full release of the compiler for a specific platform, including all the tools we ship through rustup; Those builds are then uploaded to the rust-lang-ci2 S3 bucket and are available to be locally installed with the rustup-toolchain-install-master tool. The same builds are also used for actual releases: our release process basically consists of copying those artifacts from rust-lang-ci2 to the production endpoint and signing them.

and

Non-dist jobs run our full test suite on the platform

Hence, I don't think the fortanix tests ever ran on CI

In order to mitigate LVI, all binary code needs to be mitigated. This test includes code generation for Rust code, inline assembly, global assembly and C/C++ code compiled as part of Rust crates

This is just up to the programmer though right? In the sense that you'd need to set a bunch of rather non-obvious flags for this to work at all. So I think testing the interaction with C and especially C++ is quite low.

Also, clang-11 is ancient, why is that still used? It looks like modern clang has -mlvi-hardening, but since llvm 11 the output of llvm IR has changed quite a bit so just using a more recent LLVM makes some of the tests fail.

I'm afraid that description about dist jobs not running any tests isn't quite accurate nowadays, because opt-dist do run tests (cc @Kobzol)

Well, yeah, but only on x64 Linux and MSVC, nowhere else.

jieyouxu · 2025-07-24T14:46:26Z

triagebot edited your pings out, I'll reping manually:

FYI @jethrogb @raoulstrackx @aditijannu

jieyouxu · 2025-07-24T14:48:46Z

I'll have to wait to hear back from the SGX target maintainers regarding the tests, as I don't have the context either.

@rustbot blocked (waiting to hear back)

tests/assembly-llvm/x86_64-fortanix-unknown-sgx-lvi-generic-load.rs

raoulstrackx · 2025-07-25T08:41:16Z

tests/run-make/x86_64-fortanix-unknown-sgx-lvi/rmake.rs

-    // - C/C++ code compiled as part of Rust crates
-    // For those different kinds, we do have very small code examples that should be
-    // mitigated in some way. Mostly we check that ret instructions should no longer be present.
+    cargo().arg("-v").arg("run").arg("--target").arg(target()).current_dir("enclave").run();


Yes cargo build should work just as good.

raoulstrackx · 2025-07-25T08:45:39Z

tests/run-make/x86_64-fortanix-unknown-sgx-lvi/rmake.rs

-    // - C/C++ code compiled as part of Rust crates
-    // For those different kinds, we do have very small code examples that should be
-    // mitigated in some way. Mostly we check that ret instructions should no longer be present.
+    cargo().arg("-v").arg("run").arg("--target").arg(target()).current_dir("enclave").run();


In order to mitigate LVI, all binary code needs to be mitigated. This test includes code generation for Rust code, inline assembly, global assembly and C/C++ code compiled as part of Rust crates. For the latter there need to be environment variables set:

CC_x86_64_fortanix_unknown_sgx=clang-11 \ CFLAGS_x86_64_fortanix_unknown_sgx="-D__ELF__ -isystem/usr/include/x86_64-linux-gnu -mlvi-hardening -mllvm -x86-experimental-lvi-inline-asm-hardening" \ CXX_x86_64_fortanix_unknown_sgx=clang++-11 \ CXXFLAGS_x86_64_fortanix_unknown_sgx="-D__ELF__ -isystem/usr/include/x86_64-linux-gnu -mlvi-hardening -mllvm -x86-experimental-lvi-inline-asm-hardening" \

we do that in src/ci/docker/host-x86_64/dist-various-2/Dockerfile. When testing this locally, you may not have this set.

tests/run-make/x86_64-fortanix-unknown-sgx-lvi/rmake.rs

jieyouxu · 2025-07-25T08:54:11Z

@rustbot author

rustbot · 2025-07-25T08:54:15Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

jethrogb · 2025-07-25T10:31:23Z

@folkertdev

Firstly, as far as I can tell, no CI job actually runs any of the fortanix tests?

We're a tier 2 target. So the Rust project doesn't run any tests. Fortanix has internal CI that watches the Rust repo.

folkertdev · 2025-07-25T11:09:06Z

We're a tier 2 target. So the Rust project doesn't run any tests.

Right, that makes some sense historically then. Though there is a lot of variance in what tests do get run for tier-2 targets. e.g. s390x-unknown-linux-gnu gets exercised quite a bit despite being tier 2.

For tests/assembly-llvm/x86_64-fortanix-unknown-sgx-lvi-generic-load.rs and friends, we can just run the test now with minicore from any target.

For the run-make test: why is it in-tree at all when it's not actually executed?

jethrogb · 2025-07-25T11:28:00Z

If the Rust project's policy has changed is this regard we would very much like the test suite to be run for this target as well.

folkertdev · 2025-07-25T11:47:42Z

I don't think it's changed for run-make, but for many of the other tests (e.g. assembly) we do test for more targets than just tier 1.

But run-make requires more setup, and is usually more fragile, so I do think those are limited to tier 1 targets. And then I'm still not sure why the fortanix test is in-tree.

Kobzol · 2025-07-25T12:29:32Z

As a general answer, I doubt there is a clear reason for this. The way we run tests is quite arbitrary in many ways, and there's a lot of historical cruft. So the answer can very possibly be "it's by accident".

jethrogb · 2025-07-25T12:41:12Z

I'm still not sure why the fortanix test is in-tree.

Why wouldn't the test be in-tree? Citing from the target tier policy:

The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target.

I realize this doesn't require it to be in tree, but that does seem like a logical place for it.

In addition, having it in-tree makes the most sense for future promotion to tier 1.

jieyouxu · 2025-07-25T13:20:24Z

The test changes look good to me, but since the run-make test is not exercised in CI, can one of the target maintainers @jethrogb @raoulstrackx @aditijannu confirm it works locally on the target as expected and that the test changes look good to you as well?

folkertdev · 2025-07-25T13:34:39Z

ftr even with clang-11 and the cflags from the docker file I can't get this to run locally

=== STDERR ===
unw_getcontext.checks:2:8: error: CHECK: expected string not found in input
CHECK: lfence
       ^
<stdin>:6:33: note: scanning from here
000000000008cb31 <unw_getcontext>:
                                ^
<stdin>:7:19: note: possible intended match here
 8cb31: f3 0f 1e fa endbr64
                  ^

Input file: <stdin>
Check file: unw_getcontext.checks

-dump-input=help explains the following input dump.

Input was:
<<<<<<
           1:  
           2: enclave/target/x86_64-fortanix-unknown-sgx/debug/enclave: file format elf64-x86-64 
           3:  
           4: Disassembly of section .text: 
           5:  
           6: 000000000008cb31 <unw_getcontext>: 
check:2'0                                     X~~ error: no match found
           7:  8cb31: f3 0f 1e fa endbr64 
check:2'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:2'1                       ?          possible intended match
           8:  8cb35: 48 89 07 movq %rax, (%rdi) 
check:2'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           9:  8cb38: 48 89 5f 08 movq %rbx, 0x8(%rdi) 
check:2'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          10:  8cb3c: 48 89 4f 10 movq %rcx, 0x10(%rdi) 
check:2'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          11:  8cb40: 48 89 57 18 movq %rdx, 0x18(%rdi) 
check:2'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          12:  8cb44: 48 89 7f 20 movq %rdi, 0x20(%rdi) 
check:2'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           .
           .
           .
>>>>>>
------------------------------------------



failures:
    [run-make] tests/run-make/x86_64-fortanix-unknown-sgx-lvi

(the llvm/clang is from https://www.kernel.org/pub/tools/llvm/)

folkertdev · 2025-07-26T10:29:59Z

Over in #144454 there is an uefi test (that PR makes it a run-make test) that is run in the test-various CI job. So I guess fortanix could also be tested there. I'll leave that to the target maintainers though.

raoulstrackx

I've ran these tests manually and they all succeed as expected.

tests/run-make/x86_64-fortanix-unknown-sgx-lvi/rmake.rs

Make it more idiomatic with the new run-make infra

folkertdev · 2025-07-28T11:43:58Z

I've update the commands to use generic clang (though I suspect CI will still use clang-11 in practice).

Do you have any idea what I might be missing locally that causes the failures above? This is what I run

./x test tests/run-make/x86_64-fortanix-unknown-sgx-lvi/rmake.rs  --target x86_64-fortanix-unknown-sgx

Ideally the run-make test would itself configure anything that is needed beyond that.

raoulstrackx · 2025-07-28T11:58:02Z

Thanks for the update @folkertdev !

Do you have any idea what I might be missing locally that causes the failures above?

Probably the libunwind crate wasn't rebuild with the updated environment variables. I've ran your test command as well (after building the compiler with the right environment variables) and it just works.

folkertdev · 2025-07-28T12:13:15Z

hmm I had some hope that -Zbuild-std would handle that, but apparently not.

folkertdev · 2025-08-01T17:52:41Z

@rustbot ready

At least, as far as I'm concerned. I'd like it if these tests were easier to run for outsiders, but I'll leave that with the target maintainers.

jieyouxu · 2025-08-02T07:21:22Z

@bors r+ rollup

bors · 2025-08-02T07:21:25Z

📌 Commit 8b90847 has been approved by jieyouxu

It is now in the queue for this repository.

… r=jieyouxu update fortanix tests Firstly, as far as I can tell, no CI job actually runs any of the fortanix tests? Maybe I'm missing the job that runs these tests though? In any case, the `assembly` tests now use `minicore`, meaning that they will run regardless of the host architecture (specifically, they will run during a standard PR CI build). The run-make test is actually broken, and I'd propose to make it just `cargo build` rather than `cargo run`. We can have a separate test for actually running the program, if desired. Also this test is subject to rust-lang#128733, so I'd like to re-evaluate what parts of the C/C++ compilation are actually required or useful. cc [`@jethrogb](https://github.com/jethrogb)` [`@raoulstrackx](https://github.com/raoulstrackx)` [`@aditijannu](https://github.com/aditijannu)` r? `@jieyouxu`

Rollup of 18 pull requests Successful merges: - #132748 (get rid of some false negatives in rustdoc::broken_intra_doc_links) - #135771 ([rustdoc] Add support for associated items in "jump to def" feature) - #143360 (loop match: error on `#[const_continue]` outside `#[loop_match]`) - #143662 ([rustdoc] Display unsafe attrs with edition 2024 `unsafe()` wrappers.) - #143771 (Constify some more `Result` functions) - #143900 ([rustdoc] Correctly handle `should_panic` doctest attribute and fix `--no-run` test flag on the 2024 edition) - #144185 (Document guarantees of poisoning) - #144395 (update fortanix tests) - #144478 (Improve formatting of doc code blocks) - #144614 (Fortify RemoveUnneededDrops test.) - #144703 ([test][AIX] ignore extern_weak linkage test) - #144747 (compiletest: Improve diagnostics for line annotation mismatches 2) - #144756 (detect infinite recursion with tail calls in ctfe) - #144766 (Add human readable name "Cygwin") - #144782 (Properly pass path to staged `rustc` to `compiletest` self-tests) - #144786 (Cleanup the definition of `group_type`) - #144796 (Add my previous commit name to .mailmap) - #144797 (Update safety comment for new_unchecked in niche_types) Failed merges: - #144805 (compiletest: Preliminary cleanup of `ProcRes` printing/unwinding) r? `@ghost` `@rustbot` modify labels: rollup

Rollup of 17 pull requests Successful merges: - #132748 (get rid of some false negatives in rustdoc::broken_intra_doc_links) - #143360 (loop match: error on `#[const_continue]` outside `#[loop_match]`) - #143662 ([rustdoc] Display unsafe attrs with edition 2024 `unsafe()` wrappers.) - #143771 (Constify some more `Result` functions) - #144185 (Document guarantees of poisoning) - #144395 (update fortanix tests) - #144478 (Improve formatting of doc code blocks) - #144614 (Fortify RemoveUnneededDrops test.) - #144703 ([test][AIX] ignore extern_weak linkage test) - #144747 (compiletest: Improve diagnostics for line annotation mismatches 2) - #144756 (detect infinite recursion with tail calls in ctfe) - #144766 (Add human readable name "Cygwin") - #144782 (Properly pass path to staged `rustc` to `compiletest` self-tests) - #144786 (Cleanup the definition of `group_type`) - #144796 (Add my previous commit name to .mailmap) - #144797 (Update safety comment for new_unchecked in niche_types) - #144803 (rustc-dev-guide subtree update) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #144395 - folkertdev:fortanix-run-make-test, r=jieyouxu update fortanix tests Firstly, as far as I can tell, no CI job actually runs any of the fortanix tests? Maybe I'm missing the job that runs these tests though? In any case, the `assembly` tests now use `minicore`, meaning that they will run regardless of the host architecture (specifically, they will run during a standard PR CI build). The run-make test is actually broken, and I'd propose to make it just `cargo build` rather than `cargo run`. We can have a separate test for actually running the program, if desired. Also this test is subject to #128733, so I'd like to re-evaluate what parts of the C/C++ compilation are actually required or useful. cc [``@jethrogb](https://github.com/jethrogb)`` [``@raoulstrackx](https://github.com/raoulstrackx)`` [``@aditijannu](https://github.com/aditijannu)`` r? ``@jieyouxu``

Rollup of 17 pull requests Successful merges: - rust-lang/rust#132748 (get rid of some false negatives in rustdoc::broken_intra_doc_links) - rust-lang/rust#143360 (loop match: error on `#[const_continue]` outside `#[loop_match]`) - rust-lang/rust#143662 ([rustdoc] Display unsafe attrs with edition 2024 `unsafe()` wrappers.) - rust-lang/rust#143771 (Constify some more `Result` functions) - rust-lang/rust#144185 (Document guarantees of poisoning) - rust-lang/rust#144395 (update fortanix tests) - rust-lang/rust#144478 (Improve formatting of doc code blocks) - rust-lang/rust#144614 (Fortify RemoveUnneededDrops test.) - rust-lang/rust#144703 ([test][AIX] ignore extern_weak linkage test) - rust-lang/rust#144747 (compiletest: Improve diagnostics for line annotation mismatches 2) - rust-lang/rust#144756 (detect infinite recursion with tail calls in ctfe) - rust-lang/rust#144766 (Add human readable name "Cygwin") - rust-lang/rust#144782 (Properly pass path to staged `rustc` to `compiletest` self-tests) - rust-lang/rust#144786 (Cleanup the definition of `group_type`) - rust-lang/rust#144796 (Add my previous commit name to .mailmap) - rust-lang/rust#144797 (Update safety comment for new_unchecked in niche_types) - rust-lang/rust#144803 (rustc-dev-guide subtree update) r? `@ghost` `@rustbot` modify labels: rollup

rustbot assigned jieyouxu Jul 24, 2025

rustbot added A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 24, 2025

folkertdev commented Jul 24, 2025

View reviewed changes

rustbot added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 24, 2025

raoulstrackx reviewed Jul 25, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Jul 25, 2025

folkertdev force-pushed the fortanix-run-make-test branch from e240476 to afe48b4 Compare July 25, 2025 10:58

jieyouxu added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 25, 2025

folkertdev force-pushed the fortanix-run-make-test branch from afe48b4 to 659ca90 Compare July 25, 2025 13:43

raoulstrackx approved these changes Jul 28, 2025

View reviewed changes

tests/run-make/x86_64-fortanix-unknown-sgx-lvi/rmake.rs Outdated Show resolved Hide resolved

tests/run-make/x86_64-fortanix-unknown-sgx-lvi/rmake.rs Outdated Show resolved Hide resolved

use minicore for fortanix assembly tests

91bccd6

folkertdev force-pushed the fortanix-run-make-test branch from 659ca90 to f99e14a Compare July 28, 2025 11:34

update fortanix run-make test

8b90847

Make it more idiomatic with the new run-make infra

folkertdev force-pushed the fortanix-run-make-test branch from f99e14a to 8b90847 Compare July 28, 2025 11:40

jieyouxu added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 29, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 1, 2025

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 2, 2025

samueltardieu mentioned this pull request Aug 2, 2025

Rollup of 18 pull requests #144810

Closed

samueltardieu mentioned this pull request Aug 2, 2025

Rollup of 17 pull requests #144814

Merged

bors merged commit cafd9fb into rust-lang:master Aug 3, 2025
10 checks passed

rustbot added this to the 1.90.0 milestone Aug 3, 2025

update fortanix tests #144395

update fortanix tests #144395

Conversation

folkertdev commented Jul 24, 2025

Uh oh!

rustbot commented Jul 24, 2025

Uh oh!

rustbot commented Jul 24, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jieyouxu Jul 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jieyouxu commented Jul 24, 2025

Uh oh!

jieyouxu commented Jul 24, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jieyouxu commented Jul 25, 2025

Uh oh!

rustbot commented Jul 25, 2025

Uh oh!

jethrogb commented Jul 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

folkertdev commented Jul 25, 2025

Uh oh!

jethrogb commented Jul 25, 2025

Uh oh!

folkertdev commented Jul 25, 2025

Uh oh!

Kobzol commented Jul 25, 2025

Uh oh!

jethrogb commented Jul 25, 2025

Uh oh!

jieyouxu commented Jul 25, 2025

Uh oh!

folkertdev commented Jul 25, 2025

Uh oh!

folkertdev commented Jul 26, 2025

Uh oh!

raoulstrackx left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

folkertdev commented Jul 28, 2025

Uh oh!

raoulstrackx commented Jul 28, 2025

Uh oh!

folkertdev commented Jul 28, 2025

Uh oh!

folkertdev commented Aug 1, 2025

Uh oh!

jieyouxu commented Aug 2, 2025

Uh oh!

bors commented Aug 2, 2025

Uh oh!

Uh oh!

Uh oh!

jieyouxu Jul 25, 2025 •

edited

Loading

jethrogb commented Jul 25, 2025 •

edited

Loading