All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Eliot Courtney" <ecourtney@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Joel Fernandes" <joelagnelf@nvidia.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Alistair Popple" <apopple@nvidia.com>,
	"Timur Tabi" <ttabi@nvidia.com>, <rust-for-linux@vger.kernel.org>,
	<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 02/11] gpu: nova-core: vbios: limit `BitToken` entry reads
Date: Wed, 29 Apr 2026 22:35:28 +0900	[thread overview]
Message-ID: <DI5OFKEERXGP.1EFM9XNWQQ1YA@nvidia.com> (raw)
In-Reply-To: <20260421-fix-vbios-v3-2-8f648aef7a85@nvidia.com>

On Tue Apr 21, 2026 at 5:20 PM JST, Eliot Courtney wrote:
> If `header.token_size` is smaller than `BitToken`, then we currently can
> read past the end of `image.base.data`. Check that the token size is at
> least as big as `BitToken`.
>
> Fixes: dc70c6ae2441 ("gpu: nova-core: vbios: Add support to look up PMU table in FWSEC")
> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
> ---
>  drivers/gpu/nova-core/vbios.rs | 34 +++++++++++++++++-----------------
>  1 file changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/vbios.rs b/drivers/gpu/nova-core/vbios.rs
> index 6de7e58e0da0..de856000de23 100644
> --- a/drivers/gpu/nova-core/vbios.rs
> +++ b/drivers/gpu/nova-core/vbios.rs
> @@ -423,31 +423,31 @@ impl BitToken {
>      /// Find a BIT token entry by BIT ID in a PciAtBiosImage
>      fn from_id(image: &PciAtBiosImage, token_id: u8) -> Result<Self> {
>          let header = &image.bit_header;
> +        let entry_size = usize::from(header.token_size);
> +
> +        if entry_size < size_of::<BitToken>() {
> +            return Err(EINVAL);
> +        }

You can get rid of this check if you convert the code as suggested
below.

>  
>          // Offset to the first token entry
>          let tokens_start = image.bit_offset + usize::from(header.header_size);
>  
>          for i in 0..usize::from(header.token_entries) {
> -            let entry_offset = tokens_start + (i * usize::from(header.token_size));
> -
> -            // Make sure we don't go out of bounds
> -            if entry_offset + usize::from(header.token_size) > image.base.data.len() {
> -                return Err(EINVAL);
> -            }
> +            let entry_offset = tokens_start + (i * entry_size);

Should we use checked arithmetic here?

> +            let entry = image
> +                .base
> +                .data
> +                .get(entry_offset..)
> +                .and_then(|data| data.get(..entry_size))
> +                .ok_or(EINVAL)?;
>  
>              // Check if this token has the requested ID
> -            if image.base.data[entry_offset] == token_id {
> +            if entry[0] == token_id {
>                  return Ok(BitToken {
> -                    id: image.base.data[entry_offset],
> -                    data_version: image.base.data[entry_offset + 1],
> -                    data_size: u16::from_le_bytes([
> -                        image.base.data[entry_offset + 2],
> -                        image.base.data[entry_offset + 3],
> -                    ]),
> -                    data_offset: u16::from_le_bytes([
> -                        image.base.data[entry_offset + 4],
> -                        image.base.data[entry_offset + 5],
> -                    ]),
> +                    id: entry[0],
> +                    data_version: entry[1],
> +                    data_size: u16::from_le_bytes([entry[2], entry[3]]),
> +                    data_offset: u16::from_le_bytes([entry[4], entry[5]]),

A common pattern in this file (with several such sites still to fix), is
that since Nova only supports little-endian we can leverage `FromBytes`
in order to avoid all these `from_le_bytes` call. Here this would look
as follows:

    for i in 0..usize::from(header.token_entries) {
        let entry_offset = i
            .checked_mul(entry_size)
            .and_then(|off| tokens_start.checked_add(off))
            .ok_or(EINVAL)?;

        let entry = image
            .base
            .data
            .get(entry_offset..entry_offset + entry_size)
            .and_then(|data| data.get(..entry_size))
            .ok_or(EINVAL)?;

        let (token, _) = BitToken::from_bytes_copy_prefix(entry).ok_or(EINVAL)?;

        if token.id == token_id {
            return Ok(token);
        }
    }

which has several benefits:

- No error-prone `entry[index]` accesses,
- The size check on `entry_size` is done for free by
  `from_bytes_copy_prefix`, and the slice bounds cannot be wrong,
- Shorter, more readable code overall.

Unfortunately we cannot just use `from_bytes_prefix` because we don't
have any alignment guarantee, but this is still an improvement IMHO.

If you go that way and derive `FromBytes` on `BitToken`, don't forget to
also make it `#[repr(C)]`. :)

  reply	other threads:[~2026-04-29 13:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-21  8:20 [PATCH v3 00/11] gpu: nova-core: vbios: harden various array accesses and refactor Eliot Courtney
2026-04-21  8:20 ` [PATCH v3 01/11] gpu: nova-core: vbios: fix various cases of reading past `BIOS_MAX_SCAN_LEN` Eliot Courtney
2026-04-29 13:24   ` Alexandre Courbot
2026-04-29 14:32     ` Joel Fernandes
2026-05-01  5:15       ` Eliot Courtney
2026-04-21  8:20 ` [PATCH v3 02/11] gpu: nova-core: vbios: limit `BitToken` entry reads Eliot Courtney
2026-04-29 13:35   ` Alexandre Courbot [this message]
2026-05-01  5:38     ` Eliot Courtney
2026-04-21  8:20 ` [PATCH v3 03/11] gpu: nova-core: vbios: use checked ops and accesses in `FwSecBiosImage::ucode` Eliot Courtney
2026-04-29 13:50   ` Alexandre Courbot
2026-04-21  8:20 ` [PATCH v3 04/11] gpu: nova-core: vbios: use checked access in `FwSecBiosImage::header` Eliot Courtney
2026-04-29 13:56   ` Alexandre Courbot
2026-05-01  6:07     ` Eliot Courtney
2026-04-21  8:20 ` [PATCH v3 05/11] gpu: nova-core: vbios: use checked accesses in `setup_falcon_data` Eliot Courtney
2026-04-21  8:20 ` [PATCH v3 06/11] gpu: nova-core: vbios: drop unused falcon_data_offset from FwSecBiosBuilder Eliot Courtney
2026-04-21  8:20 ` [PATCH v3 07/11] gpu: nova-core: vbios: keep PmuLookupTable local in setup_falcon_data Eliot Courtney
2026-04-21  8:20 ` [PATCH v3 08/11] gpu: nova-core: vbios: compute FWSEC-relative Falcon data offset Eliot Courtney
2026-04-21  8:20 ` [PATCH v3 09/11] gpu: nova-core: vbios: simplify setup_falcon_data Eliot Courtney
2026-04-29 14:28   ` Alexandre Courbot
2026-04-21  8:20 ` [PATCH v3 10/11] gpu: nova-core: vbios: construct `FwSecBiosImage` directly from BIOS images Eliot Courtney
2026-04-21  8:20 ` [PATCH v3 11/11] gpu: nova-core: vbios: use the first PCI-AT and FWSEC images Eliot Courtney
2026-04-29 14:32   ` Alexandre Courbot
2026-04-29 17:49     ` Gary Guo
2026-05-01 10:55       ` Eliot Courtney

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=DI5OFKEERXGP.1EFM9XNWQQ1YA@nvidia.com \
    --to=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ecourtney@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=ttabi@nvidia.com \
    /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.