cmse: clear padding when crossing the secure boundary by folkertdev · Pull Request #157397 · rust-lang/rust

folkertdev · 2026-06-03T19:01:13Z

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).

cc @Jules-Bertholet
r? @davidtwco

folkertdev · 2026-06-03T19:02:28Z

+// FIXME: dedup with the one in
+// `compiler/rustc_const_eval/src/interpret/validity.rs`
+/// Represents a set of `Size` values as a sorted list of ranges.
+// These are (offset, length) pairs, and they are sorted and mutually disjoint,
+// and never adjacent (i.e. there's always a gap between two of them).
+#[derive(Debug, Clone)]
+struct RangeSet(Vec<(Size, Size)>);


@RalfJung given the dependency graph, do you have objections to moving the rustc_const_eval into rustc_abi?

View changes since the review

moving the rustc_const_eval into rustc_abi?

... you want to move the entire crate into rustc_abi? I doubt that's what you mean. I am confused.^^

If you mean moving this data structure -- if it gets moved it should move to rustc_data_structures.

It can't due to the use of the Size type which is defined in rustc_abi.

It should probably be generic over some traits then.

Hmm, I've found something that kind of works, but rustc_const_eval uses a bunch of implementation details.

rustc_const_eval uses a bunch of implementation details.

Is that why the field is pub?

Yeah, in particular the const eval code breaks the invariant of the data structure by adding an empty range to make some other logic work out.

RalfJung · 2026-06-03T19:19:19Z

+    /// Ranges of bytes that are initialized for some valid value of this type. In particular for
+    /// enums and unions there are offsets that are initialized for some variants but not for
+    /// others.
+    fn add_data_ranges<C>(self, cx: &C, base_offset: Size, out: &mut RangeSet)


This sounds very strange. You can't just zero all bytes that would be allowed to be uninit -- that can introduce UB as it might zero something where the active enum variant says it must be non-zero.

View changes since the review

Maybe the text is not clear, but this function finds the union of all fields, not the intersection.

Specifically for e.g.

// size_of::<X>() == 8 #[repr(C, align(4))] enum X { A(u8), B(u16), }

I believe the discriminant is 32 bits here, then one variant uses 1 byte, the other 2, and this function will count the first 6 bytes as data bytes. The remaining 2 bytes are padding and should be zeroed.

I see, makes sense.

Well, kinda. Obviously the enum might be in variant A and then there's still a byte of junk being passed around here. So I hope you don't intend for this to be used for anything critical.

The entire concept of "clearing padding for security" sounds pretty backwards to me. Similar to these crates that try to "erase" secrets from memory. It's trying to shove a square into a round hole.

Well, kinda. Obviously the enum might be in variant A and then there's still a byte of junk being passed around here. So I hope you don't intend for this to be used for anything critical.

The lint in #147697 will warn on this sort of case. That PR will need some updating though after this one is merged.

That entire approach feels like piling hacks on top of hacks. I guess that's what we have to do if we want to copy what C does.

rustbot · 2026-06-03T20:16:03Z

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

davidtwco

r=me if @RalfJung is happy their comments are resolved

View changes since this review

folkertdev · 2026-06-14T10:48:16Z

In that case,

r? RalfJung

rustbot · 2026-06-14T10:48:20Z

RalfJung is not on the review rotation at the moment.
They may take a while to respond.

RalfJung

r=me with some comment nits

View changes since this review

RalfJung · 2026-06-25T10:25:35Z

+
+                if self.fn_abi.conv == CanonAbi::Arm(ArmCall::CCmseNonSecureEntry) {
+                    // The return value of an `extern "cmse-nonsecure-entry"` function crosses the secure
+                    // boundary. Zero padding bytes so information does not leak.


This should at least acknowledge that value-dependent padding is ignored, and reference somewhere that explains why that is okay.

RalfJung · 2026-06-25T10:27:06Z

                );
+
+                // The arguments of an `extern "cmse-nonsecure-call"` function cross the secure
+                // boundary. Zero padding bytes so information does not leak.


This should at least acknowledge that value-dependent padding is ignored, and reference somewhere that explains why that is okay.

rustbot · 2026-06-25T11:24:54Z

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.

folkertdev · 2026-06-25T12:56:15Z

@bors r=davidtwco,RalfJung

rust-bors · 2026-06-25T12:56:18Z

📌 Commit 5f34c50 has been approved by davidtwco,RalfJung

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 6. This pull request will be tested once the tree is reopened.

@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

Rollup of 10 pull requests Successful merges: - #158410 (Update LLVM for Mach-O __LINKEDIT alignment fix.) - #157397 (cmse: clear padding when crossing the secure boundary) - #158036 (Add -Zinstrument-mcount=fentry to -Zinstrument-mcount) - #158330 (llvm: use intrinsics for f16, f32 minimum/maximum) - #158359 (fix(tests): allow either branch direction in ilog_known_base) - #158067 (LLVM 23: Adapt codegen test to moved assume) - #158261 (Move part of the target checking for `#[may_dangle]` to the parser) - #158358 (Fix invalid E0609 raw pointer deref suggestion inside macros) - #158392 (delegation: add tests for defaults and infers in generics) - #158394 (Generate synthetic generic args only for delegation's child segment)

@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

RalfJung · 2026-06-26T08:54:22Z

Btw, is this an opsem guarantee of some sort? Does it also affect Rust-to-Rust calls and hence needs an implementation in Miri?

folkertdev · 2026-06-26T13:30:01Z

I'm not sure when something qualifies as an opsem guarantee.

The padding being cleared is something that users should be able to rely on, and it will be part of the reference. That the bytes are zeroed specifically is an implementation detail (idk we could pick 0xAA too if that had advantages). The value of the padding byte is specified to be non-deterministic (in practice it's always 0x00 but that's not guaranteed).

The clearing is only important though when the secure boundary is actually crossed, and that is impossible to do within a single program.

So practically an implementation in Miri doesn't have much use, I don't think there is any new UB that should be caught. I may be missing something though.

RalfJung · 2026-06-26T15:44:39Z

Thinking about it again, I think the change you are making here is impossible to observe in a UB-free program. Padding is reset to uninit when an argument is passed, so any program trying to check if there's a 0 there or not has UB.

folkertdev added F-cmse_nonsecure_entry `#![feature(cmse_nonsecure_entry)]` F-abi_cmse_nonsecure_call `#![feature(abi_cmse_nonsecure_call)]` labels Jun 3, 2026

rustbot assigned davidtwco Jun 3, 2026

rustbot added 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 Jun 3, 2026

folkertdev commented Jun 3, 2026

View reviewed changes

RalfJung reviewed Jun 3, 2026

View reviewed changes

Comment thread compiler/rustc_codegen_ssa/src/mir/block.rs Outdated

RalfJung reviewed Jun 3, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

folkertdev force-pushed the cmse-clear-padding branch from cb1d784 to 3be4bee Compare June 3, 2026 20:16

RalfJung reviewed Jun 4, 2026

View reviewed changes

Comment thread compiler/rustc_data_structures/src/range_set.rs Outdated

folkertdev force-pushed the cmse-clear-padding branch from 3be4bee to a037297 Compare June 4, 2026 20:55

davidtwco approved these changes Jun 12, 2026

View reviewed changes

rustbot assigned RalfJung and unassigned davidtwco Jun 14, 2026

RalfJung reviewed Jun 25, 2026

View reviewed changes

folkertdev added 4 commits June 25, 2026 13:17

add TyAndLayout::uninit_ranges

a2bb191

zero out padding in cmse entry return values

3cfdde8

zero out padding in cmse call arguments

6ce8f07

deduplicate RangeSet

5f34c50

folkertdev force-pushed the cmse-clear-padding branch from 25dc638 to 5f34c50 Compare June 25, 2026 11:24

rust-bors Bot 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 Jun 25, 2026

folkertdev mentioned this pull request Jun 25, 2026

cmse: lint on unions crossing the secure boundary #147697

Open

JonathanBrouwer mentioned this pull request Jun 25, 2026

Rollup of 8 pull requests #158414

Closed

jhpratt mentioned this pull request Jun 25, 2026

Rollup of 10 pull requests #158419

Merged

rust-bors Bot merged commit 953dec1 into rust-lang:main Jun 26, 2026
13 checks passed

rustbot added this to the 1.98.0 milestone Jun 26, 2026

Uh oh!

Uh oh!

Conversation

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

Uh oh!

Uh oh!

folkertdev Jun 3, 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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

RalfJung Jun 3, 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!

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!

RalfJung Jun 4, 2026 • 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!

This comment has been minimized.

rustbot commented Jun 3, 2026

Uh oh!

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!

folkertdev commented Jun 14, 2026

Uh oh!

rustbot commented Jun 14, 2026

Uh oh!

RalfJung 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!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Jun 25, 2026

Uh oh!

folkertdev commented Jun 25, 2026

Uh oh!

rust-bors Bot commented Jun 25, 2026

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

folkertdev commented Jun 26, 2026

Uh oh!

RalfJung commented Jun 26, 2026

Uh oh!

Reviewers

Assignees

folkertdev commented Jun 3, 2026 •

edited by rustbot

Loading

folkertdev Jun 3, 2026 •

edited by rustbot

Loading

RalfJung Jun 3, 2026 •

edited by rustbot

Loading

RalfJung Jun 4, 2026 •

edited

Loading

davidtwco left a comment •

edited by rustbot

Loading

RalfJung left a comment •

edited by rustbot

Loading

RalfJung commented Jun 26, 2026 •

edited

Loading