public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joelagnelf@nvidia.com>
To: John Hubbard <jhubbard@nvidia.com>, Danilo Krummrich <dakr@kernel.org>
Cc: "Alexandre Courbot" <acourbot@nvidia.com>,
	"Timur Tabi" <ttabi@nvidia.com>,
	"Alistair Popple" <apopple@nvidia.com>,
	"Edwin Peer" <epeer@nvidia.com>, "Zhi Wang" <zhiw@nvidia.com>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	nouveau@lists.freedesktop.org, rust-for-linux@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 21/31] gpu: nova-core: Hopper/Blackwell: add FMC signature extraction
Date: Wed, 3 Dec 2025 10:45:45 -0500	[thread overview]
Message-ID: <b9188e96-9ffa-4815-ab22-735e2506fe93@nvidia.com> (raw)
In-Reply-To: <20251203055923.1247681-22-jhubbard@nvidia.com>

Hi John,

On 12/3/2025 12:59 AM, John Hubbard wrote:
> Add extract_fmc_signatures_static() to parse cryptographic signatures
> from FMC ELF firmware sections. This extracts the SHA-384 hash, RSA
> public key, and signature needed for Chain of Trust verification.
> 
> Also exposes the elf_section() helper from firmware.rs for use by FSP.
> 
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
>  drivers/gpu/nova-core/firmware.rs |   4 +-
>  drivers/gpu/nova-core/fsp.rs      | 104 ++++++++++++++++++++++++++++++
>  2 files changed, 107 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/nova-core/firmware.rs b/drivers/gpu/nova-core/firmware.rs
> index 5cbb8be7434f..7f8d62f9ceba 100644
> --- a/drivers/gpu/nova-core/firmware.rs
> +++ b/drivers/gpu/nova-core/firmware.rs
> @@ -23,6 +23,8 @@
>      },
>  };
>  
> +pub(crate) use elf::elf_section;
> +
>  pub(crate) mod booter;
>  pub(crate) mod fsp;
>  pub(crate) mod fwsec;
> @@ -419,7 +421,7 @@ fn elf32_section<'a>(elf: &'a [u8], name: &str) -> Option<&'a [u8]> {
>      }
>  
>      /// Automatically detects ELF32 vs ELF64 based on the ELF header.
> -    pub(super) fn elf_section<'a>(elf: &'a [u8], name: &str) -> Option<&'a [u8]> {
> +    pub(crate) fn elf_section<'a>(elf: &'a [u8], name: &str) -> Option<&'a [u8]> {
>          // Check ELF magic.
>          if elf.len() < 5 || elf.get(0..4)? != b"\x7fELF" {
>              return None;
> diff --git a/drivers/gpu/nova-core/fsp.rs b/drivers/gpu/nova-core/fsp.rs
> index 389c43bfd538..311b6d4c6011 100644
> --- a/drivers/gpu/nova-core/fsp.rs
> +++ b/drivers/gpu/nova-core/fsp.rs
> @@ -256,4 +256,108 @@ pub(crate) fn wait_secure_boot(
>          })
>          .map(|_| ())
>      }
> +
> +    /// Extract FMC firmware signatures for Chain of Trust verification.
> +    ///
> +    /// Extracts real cryptographic signatures from FMC ELF32 firmware sections.
> +    /// Returns signatures in a heap-allocated structure to prevent stack overflow.
> +    pub(crate) fn extract_fmc_signatures_static(
> +        dev: &device::Device<device::Bound>,
> +        fmc_fw_data: &[u8],
> +    ) -> Result<KBox<FmcSignatures>> {
> +        dev_dbg!(dev, "FMC firmware size: {} bytes\n", fmc_fw_data.len());

Let us remove these? I think we discussed [1] that once things are working, we'd
not want these and can add it on-demand if needed.

[1] https://lore.kernel.org/all/d6c9c7f2-098e-4b55-b754-4287b698fc1c@nvidia.com/

> +
> +        // Extract hash section (SHA-384)
> +        let hash_section = crate::firmware::elf_section(fmc_fw_data, "hash")
> +            .ok_or(EINVAL)
> +            .inspect_err(|_| dev_err!(dev, "FMC firmware missing 'hash' section\n"))?;
> +
> +        // Extract public key section (RSA public key)
> +        let pkey_section = crate::firmware::elf_section(fmc_fw_data, "publickey")
> +            .ok_or(EINVAL)
> +            .inspect_err(|_| dev_err!(dev, "FMC firmware missing 'publickey' section\n"))?;
> +
> +        // Extract signature section (RSA signature)
> +        let sig_section = crate::firmware::elf_section(fmc_fw_data, "signature")
> +            .ok_or(EINVAL)
> +            .inspect_err(|_| dev_err!(dev, "FMC firmware missing 'signature' section\n"))?;
> +
> +        dev_dbg!(
> +            dev,
> +            "FMC ELF sections: hash={} bytes, pkey={} bytes, sig={} bytes\n",
> +            hash_section.len(),
> +            pkey_section.len(),
> +            sig_section.len()
> +        );
> +

Here as well.

> +        // Validate section sizes - hash must be exactly 48 bytes
> +        if hash_section.len() != FSP_HASH_SIZE {
> +            dev_err!(
> +                dev,
> +                "FMC hash section size {} != expected {}\n",
> +                hash_section.len(),
> +                FSP_HASH_SIZE
> +            );
> +            return Err(EINVAL);
> +        }
> +
> +        // Public key and signature can be smaller than the fixed array sizes
> +        if pkey_section.len() > FSP_PKEY_SIZE * 4 {
> +            dev_err!(
> +                dev,
> +                "FMC publickey section size {} > maximum {}\n",
> +                pkey_section.len(),
> +                FSP_PKEY_SIZE * 4
> +            );
> +            return Err(EINVAL);
> +        }
> +
> +        if sig_section.len() > FSP_SIG_SIZE * 4 {
> +            dev_err!(
> +                dev,
> +                "FMC signature section size {} > maximum {}\n",
> +                sig_section.len(),
> +                FSP_SIG_SIZE * 4
> +            );
> +            return Err(EINVAL);
> +        }
> +
> +        // Allocate signature structure on heap to avoid stack overflow
> +        let mut signatures = KBox::new(FmcSignatures::default(), GFP_KERNEL)?;
> +
> +        // Copy hash section directly as bytes (48 bytes exactly)
> +        // SAFETY: hash384 is a [u32; 12] array (48 bytes), and we create a byte slice of
> +        // exactly FSP_HASH_SIZE (48) bytes. The pointer is valid and properly aligned.
> +        let hash_bytes = unsafe {
> +            core::slice::from_raw_parts_mut(
> +                signatures.hash384.as_mut_ptr().cast::<u8>(),
> +                FSP_HASH_SIZE,
> +            )
> +        };
> +        hash_bytes.copy_from_slice(hash_section);
> +
> +        // Copy public key section (up to 388 bytes, zero-padded)
> +        // SAFETY: public_key is a [u32; 96] array (384 bytes), and we create a byte slice of
> +        // FSP_PKEY_SIZE * 4 bytes. The pointer is valid and properly aligned.
> +        let pkey_bytes = unsafe {
> +            core::slice::from_raw_parts_mut(
> +                signatures.public_key.as_mut_ptr().cast::<u8>(),
> +                FSP_PKEY_SIZE * 4,
> +            )
> +        };
> +        pkey_bytes[..pkey_section.len()].copy_from_slice(pkey_section);

Even if this works in practice, I believe it's UB as the `from_raw_parts_mut()`
should have the entire slice range to be valid memory (see [2]), but
FSP_PKEY_SIZE * 4 is 388 bytes while public_key is only 384 bytes ([u32; 96]).
This is vulnerable as the KBox holding the signature may not have the extra
space even if it does now.

Can we create a slice with exactly the bytes we need? something like:
let pkey_bytes = unsafe {
    core::slice::from_raw_parts_mut(
        signatures.public_key.as_mut_ptr().cast::<u8>(),
        pkey_section.len(),
    )
};
pkey_bytes.copy_from_slice(pkey_section);

Another reason for doing this is, the code is more fragile left as is, as there
is a risk of unrelated memory leaking into the slice and accessed by new/future
code.

[2] "Behavior is undefined if any of the following conditions are violated"
https://doc.rust-lang.org/std/slice/fn.from_raw_parts_mut.html

thanks,

 - Joel

> +
> +        // Copy signature section (up to 384 bytes, zero-padded)
> +        // SAFETY: signature is a [u32; 96] array (384 bytes), and we create a byte slice of
> +        // FSP_SIG_SIZE * 4 bytes. The pointer is valid and properly aligned.
> +        let sig_bytes = unsafe {
> +            core::slice::from_raw_parts_mut(
> +                signatures.signature.as_mut_ptr().cast::<u8>(),
> +                FSP_SIG_SIZE * 4,
> +            )
> +        };
> +        sig_bytes[..sig_section.len()].copy_from_slice(sig_section);
> +
> +        Ok(signatures)
> +    }
>  }


  reply	other threads:[~2025-12-03 15:45 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-03  5:58 [PATCH 00/31] gpu: nova-core: firmware: Hopper/Blackwell support John Hubbard
2025-12-03  5:58 ` [PATCH 01/31] gpu: nova-core: print FB sizes, along with ranges John Hubbard
2025-12-03 19:35   ` Timur Tabi
2025-12-04  7:27     ` John Hubbard
2026-01-13 13:28   ` Gary Guo
2026-01-13 13:42     ` Miguel Ojeda
2026-01-14  2:23     ` John Hubbard
2026-01-23  3:09       ` John Hubbard
2026-01-23 18:04         ` Gary Guo
2025-12-03  5:58 ` [PATCH 02/31] gpu: nova-core: add FbRange.len() and use it in boot.rs John Hubbard
2026-01-13 13:29   ` Gary Guo
2025-12-03  5:58 ` [PATCH 03/31] gpu: nova-core: Hopper/Blackwell: basic GPU identification John Hubbard
2025-12-03  5:58 ` [PATCH 04/31] nova-core: factor .fwsignature* selection into a new get_gsp_sigs_section() John Hubbard
2026-01-13 13:33   ` Gary Guo
2026-01-14  2:24     ` John Hubbard
2025-12-03  5:58 ` [PATCH 05/31] gpu: nova-core: use GPU Architecture to simplify HAL selections John Hubbard
2025-12-03 19:38   ` Timur Tabi
2025-12-04  7:28     ` John Hubbard
2025-12-03  5:58 ` [PATCH 06/31] gpu: nova-core: apply the one "use" item per line policy to commands.rs John Hubbard
2026-01-13 13:35   ` Gary Guo
2025-12-03  5:58 ` [PATCH 07/31] gpu: nova-core: set DMA mask width based on GPU architecture John Hubbard
2026-01-13 13:43   ` Gary Guo
2026-01-14  3:03     ` John Hubbard
2025-12-03  5:59 ` [PATCH 08/31] gpu: nova-core: move firmware image parsing code to firmware.rs John Hubbard
2026-01-13 13:44   ` Gary Guo
2025-12-03  5:59 ` [PATCH 09/31] gpu: nova-core: factor out a section_name_eq() function John Hubbard
2026-01-13 13:57   ` Gary Guo
2026-01-14  3:18     ` John Hubbard
2026-01-14 14:40       ` Gary Guo
2025-12-03  5:59 ` [PATCH 10/31] gpu: nova-core: don't assume 64-bit firmware images John Hubbard
2025-12-03  5:59 ` [PATCH 11/31] gpu: nova-core: add support for 32-bit " John Hubbard
2025-12-03  5:59 ` [PATCH 12/31] gpu: nova-core: add auto-detection of 32-bit, 64-bit " John Hubbard
2025-12-03  5:59 ` [PATCH 13/31] gpu: nova-core: Hopper/Blackwell: add FMC firmware image, in support of FSP John Hubbard
2025-12-03  5:59 ` [PATCH 14/31] gpu: nova-core: Hopper/Blackwell: add FSP falcon engine stub John Hubbard
2025-12-03  5:59 ` [PATCH 15/31] gpu: nova-core: Hopper/Blackwell: add FSP falcon EMEM operations John Hubbard
2025-12-03  6:04   ` Timur Tabi
2025-12-03  6:07     ` John Hubbard
2026-01-21 16:06   ` Gary Guo
2026-01-21 16:17     ` Miguel Ojeda
2026-01-23 23:48     ` John Hubbard
2025-12-03  5:59 ` [PATCH 16/31] gpu: nova-core: Hopper/Blackwell: add FSP message infrastructure John Hubbard
2025-12-05 16:47   ` Joel Fernandes
2026-01-03  2:15     ` John Hubbard
2025-12-03  5:59 ` [PATCH 17/31] gpu: nova-core: Hopper/Blackwell: calculate reserved FB heap size John Hubbard
2025-12-03 20:48   ` Timur Tabi
2025-12-04  7:34     ` John Hubbard
2026-01-21 16:10       ` Gary Guo
2026-01-23 23:56         ` John Hubbard
2025-12-03  5:59 ` [PATCH 18/31] gpu: nova-core: Hopper/Blackwell: add needs_large_reserved_mem() John Hubbard
2025-12-03 20:51   ` Timur Tabi
2025-12-04  7:36     ` John Hubbard
2025-12-03  5:59 ` [PATCH 19/31] gpu: nova-core: Hopper/Blackwell: add FSP secure boot completion waiting John Hubbard
2025-12-03  5:59 ` [PATCH 20/31] gpu: nova-core: Hopper/Blackwell: add FSP message structures John Hubbard
2025-12-03  5:59 ` [PATCH 21/31] gpu: nova-core: Hopper/Blackwell: add FMC signature extraction John Hubbard
2025-12-03 15:45   ` Joel Fernandes [this message]
2025-12-04  7:55     ` John Hubbard
2026-01-21 16:15   ` Gary Guo
2026-01-24  0:45     ` John Hubbard
2025-12-03  5:59 ` [PATCH 22/31] gpu: nova-core: Hopper/Blackwell: add FSP send/receive messaging John Hubbard
2025-12-03  5:59 ` [PATCH 23/31] gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot John Hubbard
2025-12-05 17:15   ` Joel Fernandes
2025-12-08  6:00     ` John Hubbard
2025-12-06 21:36   ` Joel Fernandes
2025-12-08  6:09     ` John Hubbard
2025-12-03  5:59 ` [PATCH 24/31] gpu: nova-core: Hopper/Blackwell: larger non-WPR heap John Hubbard
2026-01-21 16:18   ` Gary Guo
2026-01-24  1:50     ` John Hubbard
2025-12-03  5:59 ` [PATCH 25/31] gpu: nova-core: Hopper/Blackwell: larger WPR2 (GSP) heap John Hubbard
2025-12-03  5:59 ` [PATCH 26/31] gpu: nova-core: refactor SEC2 booter loading into run_booter() helper John Hubbard
2025-12-03 20:53   ` Timur Tabi
2025-12-04  7:37     ` John Hubbard
2025-12-03  5:59 ` [PATCH 27/31] gpu: nova-core: Hopper/Blackwell: skip GFW boot waiting John Hubbard
2025-12-03  5:59 ` [PATCH 28/31] gpu: nova-core: Hopper/Blackwell: add GSP lockdown release polling John Hubbard
2025-12-03 20:59   ` Timur Tabi
2025-12-04  7:49     ` John Hubbard
2026-01-21 16:20   ` Gary Guo
2026-01-24  1:10     ` John Hubbard
2025-12-03  5:59 ` [PATCH 29/31] gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot path John Hubbard
2026-01-21 16:35   ` Gary Guo
2026-01-24  1:38     ` John Hubbard
2026-01-24  1:42       ` John Hubbard
2026-01-26 13:08         ` Gary Guo
2026-01-26 19:53           ` John Hubbard
2025-12-03  5:59 ` [PATCH 30/31] gpu: nova-core: Hopper/Blackwell: new location for PCI config mirror John Hubbard
2025-12-03  5:59 ` [PATCH 31/31] gpu: nova-core: clarify the GPU firmware boot steps John Hubbard

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=b9188e96-9ffa-4815-ab22-735e2506fe93@nvidia.com \
    --to=joelagnelf@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=epeer@nvidia.com \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    --cc=zhiw@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox