From: John Hubbard <jhubbard@nvidia.com>
To: "Alexandre Courbot" <acourbot@nvidia.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>,
"Danilo Krummrich" <dakr@kernel.org>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>
Cc: Alistair Popple <apopple@nvidia.com>,
Joel Fernandes <joelagnelf@nvidia.com>,
Timur Tabi <ttabi@nvidia.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 3/8] gpu: nova-core: firmware: process Booter and patch its signature
Date: Tue, 26 Aug 2025 19:29:49 -0700 [thread overview]
Message-ID: <a9467dd4-6551-4ef2-b231-02d7696e2d8f@nvidia.com> (raw)
In-Reply-To: <20250826-nova_firmware-v2-3-93566252fe3a@nvidia.com>
On 8/25/25 9:07 PM, Alexandre Courbot wrote:
...
> +/// Signature parameters, as defined in the firmware.
> +#[repr(C)]
> +struct HsSignatureParams {
> + // Fuse version to use.
> + fuse_ver: u32,
> + // Mask of engine IDs this firmware applies to.
> + engine_id_mask: u32,
> + // ID of the microcode.
Should these three comments use "///" instead of "//" ?
...> +pub(crate) struct BooterFirmware {
> + // Load parameters for `IMEM` falcon memory.
> + imem_load_target: FalconLoadTarget,
> + // Load parameters for `DMEM` falcon memory.
> + dmem_load_target: FalconLoadTarget,
> + // BROM falcon parameters.
> + brom_params: FalconBromParams,
> + // Device-mapped firmware image.
> + ucode: FirmwareDmaObject<Self, Signed>,
> +}
> +
> +impl FirmwareDmaObject<BooterFirmware, Unsigned> {
> + fn new_booter(dev: &device::Device<device::Bound>, data: &[u8]) -> Result<Self> {
> + DmaObject::from_data(dev, data).map(|ucode| Self(ucode, PhantomData))
> + }
> +}
> +
> +impl BooterFirmware {
> + /// Parses the Booter firmware contained in `fw`, and patches the correct signature so it is
> + /// ready to be loaded and run on `falcon`.
> + pub(crate) fn new(
> + dev: &device::Device<device::Bound>,
> + fw: &Firmware,
> + falcon: &Falcon<<Self as FalconFirmware>::Target>,
> + bar: &Bar0,
> + ) -> Result<Self> {
> + let bin_fw = BinFirmware::new(fw)?;
A few newlines for a little visual "vertical relief" would be a
welcome break from this wall of text. Maybe one before and after
each comment+line, just for this one time here, if that's not too
excessive:
here> + // The binary firmware embeds a Heavy-Secured firmware.
> + let hs_fw = HsFirmwareV2::new(&bin_fw)?;
here> + // The Heavy-Secured firmware embeds a firmware load descriptor.
> + let load_hdr = HsLoadHeaderV2::new(&hs_fw)?;
here> + // Offset in `ucode` where to patch the signature.
> + let patch_loc = hs_fw.patch_location()?;
here> + let sig_params = HsSignatureParams::new(&hs_fw)?;
> + let brom_params = FalconBromParams {
> + // `load_hdr.os_data_offset` is an absolute index, but `pkc_data_offset` is from the
> + // signature patch location.
> + pkc_data_offset: patch_loc
> + .checked_sub(load_hdr.os_data_offset)
> + .ok_or(EINVAL)?,
> + engine_id_mask: u16::try_from(sig_params.engine_id_mask).map_err(|_| EINVAL)?,
> + ucode_id: u8::try_from(sig_params.ucode_id).map_err(|_| EINVAL)?,
> + };
> + let app0 = HsLoadHeaderV2App::new(&hs_fw, 0)?;
> +
> + // Object containing the firmware microcode to be signature-patched.
> + let ucode = bin_fw
> + .data()
> + .ok_or(EINVAL)
> + .and_then(|data| FirmwareDmaObject::<Self, _>::new_booter(dev, data))?;
> +
> + let ucode_signed = {
This ucode_signed variable is misnamed...
> + let mut signatures = hs_fw.signatures_iter()?.peekable();
> +
> + if signatures.peek().is_none() {
> + // If there are no signatures, then the firmware is unsigned.
> + ucode.no_patch_signature()
...as we can see here. :)
> + } else {
> + // Obtain the version from the fuse register, and extract the corresponding
> + // signature.
> + let reg_fuse_version = falcon.signature_reg_fuse_version(
Oh...I don't want to derail this patch review with a pre-existing problem,
but let me mention it anyway so I don't forget: .signature_reg_fuse_version()
appears to be unnecessarily HAL-ified. I think.
SEC2 boot flow only applies to Turing, Ampere, Ada, and so unless Timur
uncovers a Turing-specific signature_reg_fuse_version(), then I think
we'd best delete that entire HAL area and call it directly.
Again, nothing to do with this patch, I'm just looking for a quick
sanity check on my first reading of this situation.
> + bar,
> + brom_params.engine_id_mask,
> + brom_params.ucode_id,
> + )?;
> +
> + let signature = match reg_fuse_version {
> + // `0` means the last signature should be used.
> + 0 => signatures.last(),
Should we provide a global const, to make this concept a little more self-documenting?
Approximately:
const FUSE_VERSION_USE_LAST_SIG: u32 = 0;
> + // Otherwise hardware fuse version needs to be substracted to obtain the index.
typo: "s/substracted/subtracted/"
> + reg_fuse_version => {
> + let Some(idx) = sig_params.fuse_ver.checked_sub(reg_fuse_version) else {
> + dev_err!(dev, "invalid fuse version for Booter firmware\n");
> + return Err(EINVAL);
> + };
> + signatures.nth(idx as usize)
> + }
> + }
> + .ok_or(EINVAL)?;
> +
> + ucode.patch_signature(&signature, patch_loc as usize)?
> + }
> + };
> +
> + Ok(Self {
> + imem_load_target: FalconLoadTarget {
> + src_start: app0.offset,
> + dst_start: 0,
> + len: app0.len,
Should we check that app0.offset.checked_add(app0.len) doesn't cause an
out of bounds read?
> + },
> + dmem_load_target: FalconLoadTarget {
> + src_start: load_hdr.os_data_offset,
> + dst_start: 0,
> + len: load_hdr.os_data_size,
> + },
> + brom_params,
> + ucode: ucode_signed,
> + })
> + }
> +}
> +
> +impl FalconLoadParams for BooterFirmware {
> + fn imem_load_params(&self) -> FalconLoadTarget {
> + self.imem_load_target.clone()
> + }
> +
> + fn dmem_load_params(&self) -> FalconLoadTarget {
> + self.dmem_load_target.clone()
> + }
> +
> + fn brom_params(&self) -> FalconBromParams {
> + self.brom_params.clone()
> + }
> +
> + fn boot_addr(&self) -> u32 {
> + self.imem_load_target.src_start
> + }
> +}
> +
> +impl Deref for BooterFirmware {
> + type Target = DmaObject;
> +
> + fn deref(&self) -> &Self::Target {
> + &self.ucode.0
> + }
> +}
OK, so this allows &BooterFirmware to be used where &DmaObject is expected,
but it's not immediately obvious that BooterFirmware derefs to its internal
DMA object. It feels too clever...
Could we do something a little more obvious instead? Sort of like this:
impl BooterFirmware {
pub(crate) fn dma_object(&self) -> &DmaObject {
&self.ucode.0
}
}
...
I'm out of time today, will work on the other half of the series tomorrow.
thanks,
--
John Hubbard
next prev parent reply other threads:[~2025-08-27 2:29 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 4:07 [PATCH v2 0/8] gpu: nova-core: process and prepare more firmwares to boot GSP Alexandre Courbot
2025-08-26 4:07 ` [PATCH v2 1/8] rust: transmute: add `from_bytes_copy` method to `FromBytes` trait Alexandre Courbot
2025-08-26 6:50 ` Benno Lossin
2025-08-27 0:51 ` John Hubbard
2025-08-28 7:05 ` Alexandre Courbot
2025-08-28 11:26 ` Alexandre Courbot
2025-08-28 11:45 ` Miguel Ojeda
2025-08-29 1:51 ` Alexandre Courbot
2025-08-26 4:07 ` [PATCH v2 2/8] gpu: nova-core: firmware: add support for common firmware header Alexandre Courbot
2025-08-27 1:34 ` John Hubbard
2025-08-27 8:47 ` Alexandre Courbot
2025-08-27 21:50 ` John Hubbard
2025-08-28 7:08 ` Alexandre Courbot
2025-08-29 0:21 ` John Hubbard
2025-08-28 11:26 ` Miguel Ojeda
2025-09-10 5:44 ` Implicit panics (was: [PATCH v2 2/8] gpu: nova-core: firmware: add support for common firmware header) Alexandre Courbot
2025-09-10 10:00 ` Miguel Ojeda
2025-09-10 13:54 ` Alexandre Courbot
2025-09-10 20:57 ` Miguel Ojeda
2025-09-10 21:36 ` Implicit panics John Hubbard
2025-08-26 4:07 ` [PATCH v2 3/8] gpu: nova-core: firmware: process Booter and patch its signature Alexandre Courbot
2025-08-27 2:29 ` John Hubbard [this message]
2025-08-28 7:19 ` Alexandre Courbot
2025-08-29 0:26 ` John Hubbard
2025-08-28 20:58 ` Timur Tabi
2025-08-26 4:07 ` [PATCH v2 4/8] gpu: nova-core: firmware: process the GSP bootloader Alexandre Courbot
2025-08-28 3:09 ` John Hubbard
2025-08-26 4:07 ` [PATCH v2 5/8] gpu: nova-core: firmware: process and prepare the GSP firmware Alexandre Courbot
2025-08-28 4:01 ` John Hubbard
2025-08-28 11:13 ` Alexandre Courbot
2025-08-29 0:27 ` John Hubbard
2025-08-28 11:27 ` Danilo Krummrich
2025-08-29 11:16 ` Alexandre Courbot
2025-08-30 12:56 ` Danilo Krummrich
2025-09-01 7:11 ` Alexandre Courbot
2025-08-26 4:07 ` [PATCH v2 6/8] gpu: nova-core: firmware: use 570.144 firmware Alexandre Courbot
2025-08-28 4:07 ` John Hubbard
2025-08-26 4:07 ` [PATCH v2 7/8] gpu: nova-core: Add base files for r570.144 firmware bindings Alexandre Courbot
2025-08-28 4:08 ` John Hubbard
2025-08-26 4:07 ` [PATCH v2 8/8] gpu: nova-core: compute layout of more framebuffer regions required for GSP Alexandre Courbot
2025-08-29 23:30 ` John Hubbard
2025-08-30 0:59 ` Alexandre Courbot
2025-08-30 5:46 ` John Hubbard
2025-08-27 0:29 ` [PATCH v2 0/8] gpu: nova-core: process and prepare more firmwares to boot GSP John Hubbard
2025-08-27 8:39 ` Alexandre Courbot
2025-08-27 21:56 ` John Hubbard
2025-08-28 20:44 ` Konstantin Ryabitsev
2025-08-29 0:33 ` 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=a9467dd4-6551-4ef2-b231-02d7696e2d8f@nvidia.com \
--to=jhubbard@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=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@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=tzimmermann@suse.de \
/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
all inboxes | Powered by JetHome®