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: <CABm2a9cs+pTT49GW28QViwaK-VT3=Y+sV209-Lk5S_YxEnXv+Q@mail.gmail.com>
Date: Mon, 16 Jun 2025 16:57:54 -0300
From: Christian <christiansantoslima21@...il.com>
To: Alexandre Courbot <acourbot@...dia.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, 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, ~lkcamp/patches@...ts.sr.ht, 
	richard120310@...il.com
Subject: Re: [PATCH v7] rust: transmute: Add methods for FromBytes trait

Hi, Alexandre.

> This test won't build unless you add a
>
>     /// use kernel::transmute::FromBytes;
>
> here.

My bad, I completely forgot about it.

> I asked this in the previous revision [1] but didn't get a reply: why aren't we
> defining this as the default implementations for `FromBytes`, since must users
> will want to do exactly this anyway? I tried to do it and it failed because it
> only works if `Self` is `Sized`, and we cannot conditionally implement a
> default method of a trait.

For my part, I didn't answer your question because, IMO, I don't
really understand much of the problem and, as was pointed out before,
the implementation is incomplete, I think we're now reaching the end.

> We can, however, use a proxy trait that provides an implementation of
> `FromBytes` for any type that is `Sized`:
>
>     pub unsafe trait FromBytesSized: Sized {}
>
>     unsafe impl<T> FromBytes for T
>     where
>         T: FromBytesSized,
>     {
>         fn from_bytes(bytes: &[u8]) -> Option<&Self> {
>             if bytes.len() == core::mem::size_of::<Self>()
>                 && (bytes.as_ptr() as usize) % core::mem::align_of::<Self>() == 0
>             {
>                 let slice_ptr = bytes.as_ptr().cast::<Self>();
>                 unsafe { Some(&*slice_ptr) }
>             } else {
>                 None
>             }
>         }
>
>         fn from_mut_bytes(bytes: &mut [u8]) -> Option<&mut Self>
>         where
>             Self: AsBytes,
>         {
>             if bytes.len() == core::mem::size_of::<Self>()
>                 && (bytes.as_mut_ptr() as usize) % core::mem::align_of::<Self>() == 0
>             {
>                 let slice_ptr = bytes.as_mut_ptr().cast::<Self>();
>                 unsafe { Some(&mut *slice_ptr) }
>             } else {
>                 None
>             }
>         }
>     }
>
> You can then implement `FromBytesSized` for all the types given to
> `impl_frombytes!`.
>
> The main benefit over the `impl_frombytes!` macro is that `FromBytesSized` is
> public, and external users can just implement it on their types without having
> to provide implementations for `from_bytes` and `from_mut_bytes` which would in
> all likelihood be identical to the ones of `impl_frombytes!` anyway. And if
> they need something different, they can always implement `FromBytes` directly.
>
> For instance, the failing tests in `dma.rs` that I mentioned above can be fixed
> by making them implement `FromBytesSized` instead of `FromBytes`.

Hmm... I can change the implementation for this, but I think the idea
behind `FromBytes` and `AsBytes` is that they are the default
implementation and other parts adapt to them. Also, in the case of
Slices, since we'll use only `Sized` types, do we just abort the
conversion for them? If the maintainers are ok, I don't mind tho.

Thanks,
Christian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ