linux-kernel - Re: [PATCH v3 14/14] gpu: nova-core: gsp: Retrieve GSP static info to gather GPU information

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fab924f0-dbbc-453f-bd8e-0abe8d0bbc3e@nvidia.com>
Date: Wed, 12 Nov 2025 15:35:14 -0500
From: Joel Fernandes <joelagnelf@...dia.com>
To: Lyude Paul <lyude@...hat.com>, linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 dakr@...nel.org, acourbot@...dia.com
Cc: Alistair Popple <apopple@...dia.com>, Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
 Gary Guo <gary@...yguo.net>, bjorn3_gh@...tonmail.com,
 Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 John Hubbard <jhubbard@...dia.com>, Timur Tabi <ttabi@...dia.com>,
 joel@...lfernandes.org, Daniel Almeida <daniel.almeida@...labora.com>,
 nouveau@...ts.freedesktop.org
Subject: Re: [PATCH v3 14/14] gpu: nova-core: gsp: Retrieve GSP static info to
 gather GPU information



On 11/12/2025 3:22 PM, Joel Fernandes wrote:
> On 11/11/2025 5:02 PM, Lyude Paul wrote:
> [...]
> 
>>> +#[repr(C)]
>>> +#[derive(Debug, Copy, Clone)]
>>> +pub struct GspStaticConfigInfo_t {
>>> +    pub grCapsBits: [u8_; 23usize],
>>> +    pub gidInfo: NV2080_CTRL_GPU_GET_GID_INFO_PARAMS,
>>> +    pub SKUInfo: NV2080_CTRL_BIOS_GET_SKU_INFO_PARAMS,
>>> +    pub fbRegionInfoParams: NV2080_CTRL_CMD_FB_GET_FB_REGION_INFO_PARAMS,
>>> +    pub sriovCaps: NV0080_CTRL_GPU_GET_SRIOV_CAPS_PARAMS,
>>> +    pub sriovMaxGfid: u32_,
>>> +    pub engineCaps: [u32_; 3usize],
>>> +    pub poisonFuseEnabled: u8_,
>>> +    pub fb_length: u64_,
>>> +    pub fbio_mask: u64_,
>>> +    pub fb_bus_width: u32_,
>>> +    pub fb_ram_type: u32_,
>>> +    pub fbp_mask: u64_,
>>> +    pub l2_cache_size: u32_,
>>> +    pub gpuNameString: [u8_; 64usize],
>>> +    pub gpuShortNameString: [u8_; 64usize],
> 
> [...]
> 
>>> +mod util;
>>>  mod vbios;
>>>  
>>>  pub(crate) const MODULE_NAME: &kernel::str::CStr = <LocalModule as kernel::ModuleMetadata>::NAME;
>>> diff --git a/drivers/gpu/nova-core/util.rs b/drivers/gpu/nova-core/util.rs
>>> new file mode 100644
>>> index 000000000000..f1a4dea44c10
>>> --- /dev/null
>>> +++ b/drivers/gpu/nova-core/util.rs
>>> @@ -0,0 +1,16 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +
>>> +/// Converts a null-terminated byte array to a string slice.
>>> +///
>>> +/// Returns "invalid" if the bytes are not valid UTF-8 or not null-terminated.
>>> +pub(crate) fn str_from_null_terminated(bytes: &[u8]) -> &str {
>>> +    use kernel::str::CStr;
>>> +
>>> +    // Find the first null byte, then create a slice that includes it.
>>> +    bytes
>>> +        .iter()
>>> +        .position(|&b| b == 0)
>>> +        .and_then(|null_pos| CStr::from_bytes_with_nul(&bytes[..=null_pos]).ok())
>>> +        .and_then(|cstr| cstr.to_str().ok())
>>> +        .unwrap_or("invalid")
>>
>> I feel like I'm missing something obvious here so excuse me if I am. But if
>> CStr::from_bytes_with_nul is already scanning the string for a NULL byte, why
>> do we need to do iter().position(|&b| b == 0)?
> 
> It is because the .get() above could potentially return an entire buffer with
> no-null termintaor, as unlikely as that might be. In this case the
> `.unwrap_or(msg.gpuNameString.len() - 1),` bit will execute returning 63 as the
> length of the buffer space is 64 bytes. `CStr::from_bytes_with_nul()` will then
> separately look for the NULL and fail into returning "invalid" as the string.
> 
> So mainly, the redundant `.position()` call is it is to handle the failure case.

Sorry clarifying my answer as I was referring to the other snippet. The real
reason is from_bytes_with_nul(bytes: &[u8]) requires the slice to be exactly the
length of the string plus one byte for NULL. You can't pass it a long slice and
have interior NULLs.

This is also mentioned here:

    /// The provided slice must be `NUL`-terminated, does not contain any
    /// interior `NUL` bytes.
    pub const fn from_bytes_with_nul(bytes: &[u8]) -> Result<&Self..

It is possible that callers pass buffers with interior NULLs, these come from
the firmware. So str_from_null_terminated has to find the NULL position first.

Does that answer your question?

Thanks.