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

["Alexandre Courbot" <acourbot@nvidia.com>]

On Thu Dec 18, 2025 at 3:01 AM JST, Matthew Maurer wrote:
> On Tue, Dec 16, 2025 at 7:12 PM Alexandre Courbot <acourbot@nvidia.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@google.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.

Yeah it's probably correct as it is. I am not sure why we would want to
use it on types without a predictable layout, but also cannot say this
is fundamentally broken.