All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gary Guo <gary@garyguo.net>
To: Christian dos Santos de Lima <christiansantoslima21@gmail.com>
Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	~lkcamp/patches@lists.sr.ht
Subject: Re: [PATCH v2] rust: transmute: Add implementation for FromBytes trait
Date: Sat, 12 Oct 2024 19:36:57 +0100	[thread overview]
Message-ID: <20241012193657.290cc79c@eugeo> (raw)
In-Reply-To: <20241012070121.110481-1-christiansantoslima21@gmail.com>

On Sat, 12 Oct 2024 04:01:21 -0300
Christian dos Santos de Lima <christiansantoslima21@gmail.com> wrote:

> Add implementation and documentation for FromBytes trait.
> 
> Add new feature block in order to allow using ToBytes
> and bound to from_bytes_mut function. I'm adding this feature
> because is possible create a value with disallowed bit pattern
> and as_byte_mut could create such value by mutating the array and
> acessing the original value. So adding ToBytes this can be avoided.
> 
> Link: https://github.com/Rust-for-Linux/linux/issues/1119
> Signed-off-by: Christian dos Santos de Lima <christiansantoslima21@gmail.com>
> ---
> changes in v2:
>      - Rollback the implementation for the macro in the repository and add implementation of functions in trait
> ---
>  rust/kernel/lib.rs       |   2 +
>  rust/kernel/transmute.rs | 120 ++++++++++++++++++++++++++++-----------
>  2 files changed, 88 insertions(+), 34 deletions(-)
> 
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index dc37aef6a008..5215f5744e12 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -18,6 +18,8 @@
>  #![feature(lint_reasons)]
>  #![feature(new_uninit)]
>  #![feature(unsize)]
> +#![feature(portable_simd)]
> +#![feature(trivial_bounds)]
>  
>  // Ensure conditional compilation based on the kernel configuration works;
>  // otherwise we may silently break things like initcall handling.
> diff --git a/rust/kernel/transmute.rs b/rust/kernel/transmute.rs
> index 1c7d43771a37..bce42cc7265e 100644
> --- a/rust/kernel/transmute.rs
> +++ b/rust/kernel/transmute.rs
> @@ -2,6 +2,7 @@
>  
>  //! Traits for transmuting types.
>  
> +use core::simd::ToBytes;
>  /// Types for which any bit pattern is valid.
>  ///
>  /// Not all types are valid for all values. For example, a `bool` must be either zero or one, so
> @@ -9,15 +10,58 @@
>  ///
>  /// It's okay for the type to have padding, as initializing those bytes has no effect.
>  ///
> +/// # Example
> +///
> +/// This example is how to use the FromBytes trait
> +/// ```
> +/// // Initialize a slice of bytes
> +/// let foo = &[1, 2, 3, 4];
> +///
> +/// //Use the function implemented by trait in integer type
> +/// let result = u8::from_bytes(foo);
> +///
> +/// assert_eq!(*result, 0x4030201);
> +/// ```
>  /// # Safety
>  ///
>  /// All bit-patterns must be valid for this type. This type must not have interior mutability.
> -pub unsafe trait FromBytes {}
> +pub unsafe trait FromBytes {
> +    ///Get an imutable slice of bytes and converts to a reference to Self

missing space after `///`.

> +    unsafe fn from_bytes(slice_of_bytes: &[u8]) -> &Self;

There's no safety section. The only reason for this being unsafe is
length mismatch? I would rather have the impl perform length check and
return an Result type. If there's a case where length is known, people
can use `unwrap_unchecked` instead.

> +    /// Get a mutable slice of bytes and converts to a reference to Self
> +    ///
> +    /// # Safety
> +    ///
> +    ///  Bound ToBytes in order to avoid use with disallowed bit patterns
> +    unsafe fn from_bytes_mut(slice_of_bytes: &mut [u8]) -> &mut Self
> +    where
> +        Self: ToBytes;
> +}
>  
> +//Get a reference of slice of bytes and converts into a reference of integer or a slice with a defined size
>  macro_rules! impl_frombytes {
>      ($($({$($generics:tt)*})? $t:ty, )*) => {
>          // SAFETY: Safety comments written in the macro invocation.
> -        $(unsafe impl$($($generics)*)? FromBytes for $t {})*
> +        $(unsafe impl$($($generics)*)? FromBytes for $t {
> +            unsafe fn from_bytes(slice_of_bytes: &[u8]) -> &Self
> +            {
> +                unsafe {
> +                    let slice_ptr = slice_of_bytes.as_ptr() as *const Self;
> +                    &*slice_ptr

I don't think we want a manual implementation like this for each type
(even if it's abstracted behind macros). I'd suggestion take
inspiration from zerocopy's KnownLayout type:
https://docs.rs/zerocopy/latest/zerocopy/trait.KnownLayout.html

Best,
Gary

> +                }
> +            }
> +
> +            unsafe fn from_bytes_mut(slice_of_bytes: &mut [u8]) -> &mut Self
> +            where
> +                Self: ToBytes,
> +            {
> +                unsafe {
> +                    let slice_ptr = slice_of_bytes.as_mut_ptr() as *mut Self;
> +                    &mut *slice_ptr
> +                }
> +
> +            }
> +        })*
>      };
>  }
>  
> @@ -28,44 +72,52 @@ macro_rules! impl_frombytes {
>  
>      // SAFETY: If all bit patterns are acceptable for individual values in an array, then all bit
>      // patterns are also acceptable for arrays of that type.
> -    {<T: FromBytes>} [T],
>      {<T: FromBytes, const N: usize>} [T; N],
>  }
>  
> -/// Types that can be viewed as an immutable slice of initialized bytes.
> +/// Get a reference of slice of bytes and converts into a reference of an array of integers
>  ///
> -/// If a struct implements this trait, then it is okay to copy it byte-for-byte to userspace. This
> -/// means that it should not have any padding, as padding bytes are uninitialized. Reading
> -/// uninitialized memory is not just undefined behavior, it may even lead to leaking sensitive
> -/// information on the stack to userspace.
> +/// Types for which any bit pattern is valid.
>  ///
> -/// The struct should also not hold kernel pointers, as kernel pointer addresses are also considered
> -/// sensitive. However, leaking kernel pointers is not considered undefined behavior by Rust, so
> -/// this is a correctness requirement, but not a safety requirement.
> +/// Not all types are valid for all values. For example, a `bool` must be either zero or one, so
> +/// reading arbitrary bytes into something that contains a `bool` is not okay.
>  ///
> -/// # Safety
> +/// It's okay for the type to have padding, as initializing those bytes has no effect.
>  ///
> -/// Values of this type may not contain any uninitialized bytes. This type must not have interior
> -/// mutability.
> -pub unsafe trait AsBytes {}
> -
> -macro_rules! impl_asbytes {
> -    ($($({$($generics:tt)*})? $t:ty, )*) => {
> -        // SAFETY: Safety comments written in the macro invocation.
> -        $(unsafe impl$($($generics)*)? AsBytes for $t {})*
> -    };
> -}
> -
> -impl_asbytes! {
> -    // SAFETY: Instances of the following types have no uninitialized portions.
> -    u8, u16, u32, u64, usize,
> -    i8, i16, i32, i64, isize,
> -    bool,
> -    char,
> -    str,
> +/// # Example
> +///
> +/// This example is how to use the FromBytes trait
> +/// ```
> +/// // Initialize a slice of bytes
> +/// let foo = &[1, 2, 3, 4];
> +///
> +/// //Use the function implemented by trait in integer type
> +/// let result = <[u32]>::from_bytes(slice_of_bytes);
> +///
> +/// assert_eq!(*result, 0x4030201);
> +/// ```
> +// SAFETY: If all bit patterns are acceptable for individual values in an array, then all bit
> +// patterns are also acceptable for arrays of that type.
> +unsafe impl<T: FromBytes> FromBytes for [T] {
> +    unsafe fn from_bytes(slice_of_bytes: &[u8]) -> &Self {
> +        //Safety: Guarantee that all values are initiliazed
> +        unsafe {
> +            let slice_ptr = slice_of_bytes.as_ptr() as *const T;
> +            let slice_len = slice_of_bytes.len() / core::mem::size_of::<T>();
> +            core::slice::from_raw_parts(slice_ptr, slice_len)
> +        }
> +    }
>  
> -    // SAFETY: If individual values in an array have no uninitialized portions, then the array
> -    // itself does not have any uninitialized portions either.
> -    {<T: AsBytes>} [T],
> -    {<T: AsBytes, const N: usize>} [T; N],
> +    //Safety: Guarantee that all values are initiliazed
> +    unsafe fn from_bytes_mut(slice_of_bytes: &mut [u8]) -> &mut Self
> +    where
> +        Self: ToBytes,
> +    {
> +        //Safety: Guarantee that all values are initiliazed
> +        unsafe {
> +            let slice_ptr = slice_of_bytes.as_mut_ptr() as *mut T;
> +            let slice_len = slice_of_bytes.len() / core::mem::size_of::<T>();
> +            core::slice::from_raw_parts_mut(slice_ptr, slice_len)
> +        }
> +    }
>  }


  parent reply	other threads:[~2024-10-12 18:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-12  7:01 [PATCH v2] rust: transmute: Add implementation for FromBytes trait Christian dos Santos de Lima
2024-10-12  7:37 ` Dirk Behme
2024-10-12 18:36 ` Gary Guo [this message]
2024-10-16  1:26 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241012193657.290cc79c@eugeo \
    --to=gary@garyguo.net \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=christiansantoslima21@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=~lkcamp/patches@lists.sr.ht \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.