cmse: lint on unions crossing the secure boundary by folkertdev · Pull Request #147697 · rust-lang/rust

folkertdev · 2025-10-14T19:06:07Z

tracking issue: #81391
tracking issue: #75835

When a union passes from secure to non-secure (so, passed as an argument to a non-secure call, or returned by a non-secure entry), warn that there may be secure information lingering in the unused or uninitialized parts of a union value.

This lint matches the behavior of clang (see https://godbolt.org/z/vq9xnrnEs). Like clang we warn at the use site, so that individual uses could be annotated with #[allow(cmse_uninitialized_leak)].

Ideally we'd warn on any type that may have uninitialized parts, but I haven't figured out a good way to do that yet.

It is still unclear whether a union value where all fields are equally large and allow the same bit patterns can be considered initialized (see rust-lang/unsafe-code-guidelines#438), so for now we just warn on any union.

r? @ghost

folkertdev · 2025-10-15T19:29:31Z

r? @davidtwco

This seems useful just for parity with clang. The code is built to be extended to cover more cases of types possibly containing uninitialized memory, but by the looks of things there isn't currently a straightforward way to detect such types (cc #t-compiler/help > check whether a type can be (partially) uninitialized)

rustbot · 2025-10-15T19:29:35Z

HIR ty lowering was modified

cc @fmease

This PR modifies tests/auxiliary/minicore.rs.

cc @jieyouxu

davidtwco

Implementation LGTM, two nits, but will need t-lang approval for a new lint

View changes since this review

davidtwco · 2025-10-16T15:47:28Z

+use minicore::*;
+
+#[repr(Rust)]
+pub union ReprRustUnionU64 {


Can you add cases where the unions are contained within other types to these tests?

folkertdev

The lint will only fire when the cmse ABIs are enabled, but I suppose the name does sort of "leak".

the OP here provides some context. The bigger picture is in this draft RFC that I plan to formally submit soon.

View changes since this review

folkertdev · 2025-10-16T20:09:35Z

+warning: passing a union across the security boundary may leak information
+  --> $DIR/return-uninitialized.rs:46:5
+   |
+LL | /     match 0 {
+LL | |
+LL | |         0 => Wrapper(ReprRustUnionU64 { _unused: 1 }),
+LL | |         _ => Wrapper(ReprRustUnionU64 { _unused: 2 }),
+LL | |     }
+   | |_____^
+   |


would it make sense to warn in the individual arms of the match instead? I think as a user that would be better in this simple case, though I don't know that we can make that robust (e.g. thinking about labeled blocks).

joshtriplett · 2025-10-22T16:04:46Z

Ideally we'd warn on any type that may have uninitialized parts, but I haven't figured out a good way to do that yet.

Would that also include padding?

In any case, this seems wildly useful for many users, not just cmse. The Linux kernel would likely benefit from this, for instance, to avoid leaking uninitialized bits to userspace.

On that basis I'm wondering if we should aspirationally call this uninitialized_leak or similar, without cmse in it.

Is there some means by which we could allow the user to suppress this not by allow but by demonstrating that they've properly zero-initialized it? Or is the point that LLVM doesn't guarantee that because it might un-zero that memory (e.g. copying without caring what value ends up in the padding / unused-union-bits / etc)?

folkertdev · 2025-10-22T16:15:43Z

Would that also include padding?

Ideally, yes. But I don't have a good strategy for actually achieving that. Based on #t-compiler/help > check whether a type can be (partially) uninitialized @ 💬 maybe there are parts of safe transmute that are helpful here.

Is there some means by which we could allow the user to suppress this not by allow but by demonstrating that they've properly zero-initialized it? Or is the point that LLVM doesn't guarantee that because it might un-zero that memory (e.g. copying without caring what value ends up in the padding / unused-union-bits / etc)?

I'm not familiar enough with the opsem details here, but in any case I don't think we'd want to tie our lints to LLVM implementation details that much?

joshtriplett · 2025-10-22T17:24:29Z

I'm not proposing to depend on LLVM details. I was asking how we can handle code that's doing the correct thing (whatever that might be), such as ensuring the uninitialized memory is zero.

In C, you would ensure the union is zero-initialized, then initialize the correct field, then return it. What's the equivalent operation that you can do in Rust, and can we ensure that we don't emit the lint if you properly do that?

folkertdev · 2025-10-22T17:29:06Z

What I had in mind is to use MaybeUninit::zeroed, set the relevant fields, and assume_init.

At least in that case, I don't think we have a good way of checking whether the value is properly initialized without actually evaluating the program (e.g. with miri).

Jules-Bertholet · 2026-03-23T16:28:26Z

(Repeating my comment on the RFC: rust-lang/rfcs#3884 (comment))

Rust doesn't preserve padding on typed copies (and, IIRC, nor does C). Any padding in a value passed to a function call can just be zeroed. There is no need to lint if this is implemented properly (presumably by the backend?).

… r=WaffleLapkin cmse: test returning `MaybeUninit<T>` tracking issue: rust-lang#81391 tracking issue: rust-lang#75835 Some tests from rust-lang#147697 that already work and are useful. Extracting them shrinks that (currently blocked) PR. The code in `tests/ui/cmse-nonsecure/cmse-nonsecure-call/return-via-stack.rs` checks that `MaybeUninit<T>` is considered abi-compatible with `T`. The code in `tests/ui/cmse-nonsecure/cmse-nonsecure-entry/params-via-stack.rs` really only tests that no errors/warnings are emitted. r? davidtwco

Rollup merge of #155522 - folkertdev:cmse-test-maybe-uninit, r=WaffleLapkin cmse: test returning `MaybeUninit<T>` tracking issue: #81391 tracking issue: #75835 Some tests from #147697 that already work and are useful. Extracting them shrinks that (currently blocked) PR. The code in `tests/ui/cmse-nonsecure/cmse-nonsecure-call/return-via-stack.rs` checks that `MaybeUninit<T>` is considered abi-compatible with `T`. The code in `tests/ui/cmse-nonsecure/cmse-nonsecure-entry/params-via-stack.rs` really only tests that no errors/warnings are emitted. r? davidtwco

rustbot · 2026-06-25T17:16:41Z

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

folkertdev · 2026-06-25T17:19:09Z

This is still waiting for #157397, but I've updated the lint to now find value-dependent padding (so, bytes that are padding only for some, but not all, valid values of the type).

@Jules-Bertholet

…avidtwco,RalfJung cmse: clear padding when crossing the secure boundary tracking issue: rust-lang#81391 tracking issue: rust-lang#75835 RFC: rust-lang/rfcs#3884 related: rust-lang#147697 quick context: cmse creates a distinction between code running in secure mode and non-secure mode (think kernel space versus user space). Secure mode has access to data (e.g. encryption keys) that must not leak to non-secure mode. They use a special calling convention that clears unused registers, but padding in arguments/return values can contain stale secure data. This PR clears the padding bytes (and similar, e.g. space not used in any variant of a union/enum) when values are passed over the secure boundary. Separately we'll have a lint to warn on enums and unions being passed across the boundary: for them we can't statically know whether the variant that is passed contains padding. This is conceptually modeled after a similar feature in `clang` ([implementation](https://github.com/llvm/llvm-project/blob/065a39b9f7f06fca0926394096ee1c1fac41d446/clang/lib/CodeGen/CGCall.cpp#L4041-L4087)). cc @Jules-Bertholet r? @davidtwco

@Jules-Bertholet

…avidtwco,RalfJung cmse: clear padding when crossing the secure boundary tracking issue: rust-lang#81391 tracking issue: rust-lang#75835 RFC: rust-lang/rfcs#3884 related: rust-lang#147697 quick context: cmse creates a distinction between code running in secure mode and non-secure mode (think kernel space versus user space). Secure mode has access to data (e.g. encryption keys) that must not leak to non-secure mode. They use a special calling convention that clears unused registers, but padding in arguments/return values can contain stale secure data. This PR clears the padding bytes (and similar, e.g. space not used in any variant of a union/enum) when values are passed over the secure boundary. Separately we'll have a lint to warn on enums and unions being passed across the boundary: for them we can't statically know whether the variant that is passed contains padding. This is conceptually modeled after a similar feature in `clang` ([implementation](https://github.com/llvm/llvm-project/blob/065a39b9f7f06fca0926394096ee1c1fac41d446/clang/lib/CodeGen/CGCall.cpp#L4041-L4087)). cc @Jules-Bertholet r? @davidtwco

@Jules-Bertholet

Rollup merge of #157397 - folkertdev:cmse-clear-padding, r=davidtwco,RalfJung cmse: clear padding when crossing the secure boundary tracking issue: #81391 tracking issue: #75835 RFC: rust-lang/rfcs#3884 related: #147697 quick context: cmse creates a distinction between code running in secure mode and non-secure mode (think kernel space versus user space). Secure mode has access to data (e.g. encryption keys) that must not leak to non-secure mode. They use a special calling convention that clears unused registers, but padding in arguments/return values can contain stale secure data. This PR clears the padding bytes (and similar, e.g. space not used in any variant of a union/enum) when values are passed over the secure boundary. Separately we'll have a lint to warn on enums and unions being passed across the boundary: for them we can't statically know whether the variant that is passed contains padding. This is conceptually modeled after a similar feature in `clang` ([implementation](https://github.com/llvm/llvm-project/blob/065a39b9f7f06fca0926394096ee1c1fac41d446/clang/lib/CodeGen/CGCall.cpp#L4041-L4087)). cc @Jules-Bertholet r? @davidtwco

…boundary When a union passes from secure to non-secure (so, passed as an argument to an nonsecure call, or returned by a nonsecure entry), warn that there may be secure information lingering in the unused or uninitialized parts of a union value. https://godbolt.org/z/vq9xnrnEs

Any guaranteed padding (bytes that are padding regardless of the value of the type) are now zeroed, so we only need to lint on enums and unions where some offsets are padding for some variants, but not for others.

rustbot · 2026-06-26T07:45:08Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

RalfJung · 2026-06-26T08:53:39Z

+            Variants::Multiple { variants, .. } => {
+                // A byte is data for every value only when it is data for every value of every
+                // variant.
+                out = variants
+                    .indices()
+                    .map(|variant| self.for_variant(cx, variant))
+                    .map(|variant| variant.always_data_ranges(cx, base_offset))
+                    .reduce(|acc, f| acc.intersection(&f))
+                    .unwrap_or(out);
+            }


I think this does not properly account for the discriminant.

Also someone familiar with our async lowering should ensure that this behaves correctly for generators/coroutines,

View changes since the review

You're right, and the docs here are all a bit confusing. Anyhow, I think just also iterating over the fields is sufficient. At least it mentions some details about coroutines.

Yeah I think it should be something like

intersect all the variants

then union that with all the fields

RalfJung · 2026-06-26T15:10:02Z

+            continue;
+        };
+
+        if !layout.variant_dependent_padding_ranges(cx).is_empty() {


This seems... potentially problematic. Whether we emit this lint now depends on incredibly unstable details of the layout algorithm. Is that really what we want?

What I expected is that we just lint about every union and enum, to avoid having the lint suddenly pop up when we change the layout of enums. Any code that relies on "yes this is an enum but there's no value-dependent padding" is relying on layout details we don't guarantee, and thus IMO fundamentally broken.

View changes since the review

Well this calling convention is a variant of the C calling convention, used for FFI, so user should be using a stable layout, likely repr(C). In that case the layout is perfectly stable.

I want the lint to actually be used, and for that it helps to have few false positives. So I expect this to work well in practice, even though it is inelegant in theory.

It's not about elegance, it's about our ability to continue evolving the layout algorithm. It's about Hyrum's law.

rust-bors · 2026-06-28T14:58:10Z

☔ The latest upstream changes (presumably #157575) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

folkertdev added F-cmse_nonsecure_entry `#![feature(cmse_nonsecure_entry)]` F-abi_cmse_nonsecure_call `#![feature(abi_cmse_nonsecure_call)]` labels Oct 14, 2025

This comment has been minimized.

Sign in to view

folkertdev force-pushed the cmse-lint-on-uninitialized branch from a344d30 to 514010e Compare October 15, 2025 09:09

This comment has been minimized.

Sign in to view

folkertdev force-pushed the cmse-lint-on-uninitialized branch from 514010e to 9d276b5 Compare October 15, 2025 11:03

This comment has been minimized.

Sign in to view

folkertdev force-pushed the cmse-lint-on-uninitialized branch from 9d276b5 to 4a269f5 Compare October 15, 2025 11:55

This comment has been minimized.

Sign in to view

folkertdev force-pushed the cmse-lint-on-uninitialized branch from 4a269f5 to 0b424f6 Compare October 15, 2025 16:49

rustbot assigned davidtwco Oct 15, 2025

folkertdev marked this pull request as ready for review October 15, 2025 19:29

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 Oct 15, 2025

davidtwco approved these changes Oct 16, 2025

View reviewed changes

davidtwco added the I-lang-nominated Nominated for discussion during a lang team meeting. label Oct 16, 2025

folkertdev force-pushed the cmse-lint-on-uninitialized branch from 0b424f6 to 4586300 Compare October 16, 2025 20:05

folkertdev commented Oct 16, 2025

View reviewed changes

traviscross added the P-lang-drag-1 Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang label Oct 22, 2025

traviscross removed I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-1 Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang labels Oct 29, 2025

folkertdev mentioned this pull request Nov 24, 2025

CMSE calling conventions rust-lang/rfcs#3884

Open

folkertdev force-pushed the cmse-lint-on-uninitialized branch from 5abb0ff to 9e50dc6 Compare April 19, 2026 16:23

This comment has been minimized.

Sign in to view

folkertdev mentioned this pull request Apr 19, 2026

cmse: test returning MaybeUninit<T> #155522

Merged

This comment has been minimized.

Sign in to view

folkertdev mentioned this pull request Jun 3, 2026

cmse: clear padding when crossing the secure boundary #157397

Merged

folkertdev force-pushed the cmse-lint-on-uninitialized branch from 9e50dc6 to d524a62 Compare June 25, 2026 17:16

This comment has been minimized.

Sign in to view

folkertdev added 3 commits June 26, 2026 09:10

only lint on value-dependent padding

a918fcd

Any guaranteed padding (bytes that are padding regardless of the value of the type) are now zeroed, so we only need to lint on enums and unions where some offsets are padding for some variants, but not for others.

tweak the error message

f9be9c7

folkertdev force-pushed the cmse-lint-on-uninitialized branch from d524a62 to f9be9c7 Compare June 26, 2026 07:45

RalfJung reviewed Jun 26, 2026

View reviewed changes

folkertdev added 3 commits June 26, 2026 10:59

rename, simplify

cf86504

tweak the error message

1e1f8c1

fix discriminant getting skipped

2f650aa

folkertdev force-pushed the cmse-lint-on-uninitialized branch from 7b92511 to 2f650aa Compare June 26, 2026 14:14

RalfJung reviewed Jun 26, 2026

View reviewed changes

Uh oh!

Uh oh!

Conversation

folkertdev commented Oct 14, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

folkertdev commented Oct 15, 2025

Uh oh!

rustbot commented Oct 15, 2025

Uh oh!

davidtwco left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

davidtwco Oct 16, 2025

Choose a reason for hiding this comment

Uh oh!

folkertdev left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

folkertdev Oct 16, 2025

Choose a reason for hiding this comment

Uh oh!

joshtriplett commented Oct 22, 2025

Uh oh!

folkertdev commented Oct 22, 2025

Uh oh!

joshtriplett commented Oct 22, 2025

Uh oh!

folkertdev commented Oct 22, 2025

Uh oh!

Jules-Bertholet commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

rustbot commented Jun 25, 2026

Uh oh!

This comment has been minimized.

folkertdev commented Jun 25, 2026

Uh oh!

This comment has been minimized.

rustbot commented Jun 26, 2026

Uh oh!

RalfJung Jun 26, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

folkertdev Jun 26, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Jun 26, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Jun 26, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

folkertdev Jun 26, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Jun 26, 2026

Choose a reason for hiding this comment

Uh oh!

rust-bors Bot commented Jun 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

folkertdev commented Oct 14, 2025 •

edited by rustbot

Loading

davidtwco left a comment •

edited by rustbot

Loading

folkertdev left a comment •

edited by rustbot

Loading

Jules-Bertholet commented Mar 23, 2026 •

edited

Loading

RalfJung Jun 26, 2026 •

edited by rustbot

Loading

RalfJung Jun 26, 2026 •

edited by rustbot

Loading