linux-kernel - Re: [PATCH v2 2/3] rust: Add support for deriving `AsBytes` and `FromBytes`

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGSQo00qe74q-Ztn2UubrMR+F-knO-DhrznSgM8Gk3j9OjNfKg@mail.gmail.com>
Date: Wed, 17 Dec 2025 10:01:32 -0800
From: Matthew Maurer <mmaurer@...gle.com>
To: Alexandre Courbot <acourbot@...dia.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, 
	Danilo Krummrich <dakr@...nel.org>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/3] rust: Add support for deriving `AsBytes` and `FromBytes`

On Tue, Dec 16, 2025 at 7:12 PM Alexandre Courbot <acourbot@...dia.com> wrote:
>
> On Tue Dec 16, 2025 at 9:44 AM JST, Matthew Maurer wrote:
> > This provides a derive macro for `AsBytes` and `FromBytes` for structs
> > only. For both, it checks the respective trait on every underlying
> > field. For `AsBytes`, it emits a const-time padding check that will fail
> > the compilation if derived on a type with padding.
> >
> > Signed-off-by: Matthew Maurer <mmaurer@...gle.com>
>
> I like this a lot. We have a bunch of unsafe impls in Nova that this
> could help us get rid of.
>
> Amazed that this even seems to work on tuple structs!
>
> > ---
> >  rust/macros/lib.rs       | 63 ++++++++++++++++++++++++++++++++++++++++++++++++
> >  rust/macros/transmute.rs | 58 ++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 121 insertions(+)
> >
> > diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
> > index b38002151871a33f6b4efea70be2deb6ddad38e2..d66397942529f67697f74a908e257cacc4201d84 100644
> > --- a/rust/macros/lib.rs
> > +++ b/rust/macros/lib.rs
> > @@ -20,9 +20,14 @@
> >  mod kunit;
> >  mod module;
> >  mod paste;
> > +mod transmute;
> >  mod vtable;
> >
> >  use proc_macro::TokenStream;
> > +use syn::{
> > +    parse_macro_input,
> > +    DeriveInput, //
> > +};
> >
> >  /// Declares a kernel module.
> >  ///
> > @@ -475,3 +480,61 @@ pub fn paste(input: TokenStream) -> TokenStream {
> >  pub fn kunit_tests(attr: TokenStream, ts: TokenStream) -> TokenStream {
> >      kunit::kunit_tests(attr, ts)
> >  }
> > +
> > +/// Implements `FromBytes` for a struct.
> > +///
> > +/// It will fail compilation if the struct you are deriving on cannot be determined to implement
> > +/// `FromBytes` safely. It may still fail for some types which would be safe to implement
> > +/// `FromBytes` for, in which case you will need to write the implementation and justification
> > +/// yourself.
> > +///
> > +/// Main reasons your type may be rejected:
> > +/// * Not a `struct`
> > +/// * One of the fields is not `FromBytes`
> > +///
> > +/// # Examples
> > +///
> > +/// ```
> > +/// #[derive(FromBytes)]
> > +/// #[repr(C)]
> > +/// struct Foo {
> > +///   x: u32,
> > +///   y: u16,
> > +///   z: u16,
> > +/// }
> > +/// ```
>
> One thing I have noticed is that I could sucessfully derive `FromBytes`
> on a struct that is not `repr(C)`... Is that something we want to
> disallow?
>

Why should we disallow this? I can enforce it very easily if we want
it, but the only difference between `#[repr(C)]` and `#[repr(Rust)]`
is whether we can statically predict their layout. In theory you can
use this to elide the padding check for `#[repr(C)]` structs (and
`zerocopy` does this), but it's significantly more complicated.

The only argument I see in favor of disallowing `#[repr(Rust)]` here
is that if it's not a struct that also supports `AsBytes`, there's a
question about where you're getting the bytes to load from.

I will point out that we probably don't *just* want to restrict to
`#[repr(C)]` because `#[repr(transparent)]` and `#[repr(packed)]` are
also great use cases.