cmse: lint on unions crossing the secure boundary

[folkertdev]

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]

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]

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]

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]

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]

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]

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]

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]

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

[folkertdev]

This PR was discussed today in the T-lang triage meeting

https://hackmd.io/Oo0T829rSfeGYTdZixvI_Q#cmse-lint-on-unions-crossing-the-secure-boundary-rust147697

Generally everyone seemed in favor. We decided to wait with actually merging this PR until the CMSE RFC is up (and perhaps accepted). That way we have a bit more time to see if there is significant overlap with RfL, look at additionally linting on values with padding, and see how it feels to use this lint in practice.

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[rustbot]

This PR was rebased onto a different master 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]

The latest commit additionally lints on types with padding:

// This is an aggregate that cannot be unwrapped, and has 1 (uninitialized) padding byte.
#[repr(C)]
struct PaddedStruct {
    a: u8,
    b: u16,
}

#[no_mangle]
extern "cmse-nonsecure-entry" fn padded_struct() -> PaddedStruct {
    PaddedStruct { a: 0, b: 1 }
    //~^ WARN passing a (partially) uninitialized value across the security boundary may leak information
}

The approach is to check whether a type T can be safely transmuted to [u8; size_of::<T>()] using the internal machinery from rustc_transmute that is also used for "safe transmute" (#![feature(transmutability)]).

This seems to work nicely for both unions and structs with padding. For unions it is also more accurate, in that e.g. #[repr(Rust)] union { _a: i64 } is considered fully initialized. What I am not 100% sure on is what the edge cases are.

Also by the looks of it the transmute logic is fairly robust, but someone more familiar with rustc_transmute should judge whether we're potentially indirectly using/stabilizing functionality that we shouldn't.

[bors]

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