Re: [PATCH 3/7] drm/nova: use `zerocopy` in booter.rs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Firmware structures are parsed using native integer types, causing endianness mismatches on big-endian architectures.
--

commit f0a0d5143a0bf185e80fec9d804b5bc8f1e3c0b1
Author: Pedro Yudi Honda <niyudi.honda@usp.br>

drm/nova: use zerocopy in booter.rs

This commit replaces the transmute::FromBytes traits with their
zerocopy::FromBytes equivalents in the firmware/booter.rs file. It updates the
call sites and struct derivations to match the new library usage.

> diff --git a/drivers/gpu/nova-core/firmware/booter.rs b/drivers/gpu/nova-core/firmware/booter.rs
> index d9313ac361af3..0cda2c50fbbe9 100644
> --- a/drivers/gpu/nova-core/firmware/booter.rs
> +++ b/drivers/gpu/nova-core/firmware/booter.rs

[ ... ]

> @@ -44,7 +43,7 @@ fn frombytes_at<S: FromBytes + Sized>(slice: &[u8], offset: usize) -> Result<S>
>      let end = offset.checked_add(size_of::<S>()).ok_or(EINVAL)?;
>      slice
>          .get(offset..end)
> -        .and_then(S::from_bytes_copy)
> +        .and_then(|b| S::read_from_bytes(b).ok())
>          .ok_or(EINVAL)
>  }
>  
> @@ -53,7 +52,7 @@ fn frombytes_at<S: FromBytes + Sized>(slice: &[u8], offset: usize) -> Result<S>
>  /// Such firmwares have an application-specific payload that needs to be patched with a given
>  /// signature.
>  #[repr(C)]
> -#[derive(Debug, Clone)]
> +#[derive(Debug, Clone, FromBytes)]
>  struct HsHeaderV2 {
>      /// Offset to the start of the signatures.
>      sig_prod_offset: u32,
>      /// Size of the signatures.
>      sig_prod_size: u32,

[Severity: High]
This is a pre-existing issue, but does using native integer types like u32
in firmware structures cause endianness mismatches on big-endian architectures?

When frombytes_at() reads the firmware headers directly from fixed-endian
firmware blobs into host-endian structures using S::read_from_bytes(b), the
driver will parse incorrect offset and size values on big-endian systems.

Should these structures be updated to use explicitly endian-aware types (like
kernel::types::Le32) for fields such as sig_prod_offset and sig_prod_size to
ensure correct parsing across all architectures and avoid potential
out-of-bounds memory accesses?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260625205146.5047-1-niyudi.honda@usp.br?part=3