From: John Hubbard <jhubbard@nvidia.com>
To: Joel Fernandes <joelagnelf@nvidia.com>,
Alistair Popple <apopple@nvidia.com>
Cc: "Dirk Behme" <dirk.behme@gmail.com>,
"Alexandre Courbot" <acourbot@nvidia.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"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>,
"Trevor Gross" <tmgross@umich.edu>,
"Timur Tabi" <ttabi@nvidia.com>, "Edwin Peer" <epeer@nvidia.com>,
"nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"rust-for-linux@vger.kernel.org" <rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH 2/4] gpu: nova-core: gsp: Fix length of received messages
Date: Mon, 15 Dec 2025 11:46:10 +0900 [thread overview]
Message-ID: <37cc2302-6a3d-4046-b28c-605221a67329@nvidia.com> (raw)
In-Reply-To: <B5724DA0-6031-4576-9B3D-DB67569711A2@nvidia.com>
On 12/15/25 10:22 AM, Joel Fernandes wrote:
>> On Dec 15, 2025, at 8:43 AM, Alistair Popple <apopple@nvidia.com> wrote:...
>> So the above calculation expands to:
>>
>> msg_length = size_of::<Self>() - size_of::<bindings::rpc_message_header_v>()
>> + num::u32_as_usize(self.inner.rpc.length) - size_of::<GspMsgElement>();
>>
>> Where self.inner.rpc.length is guaranteed to be >= size_of::<rpc_message_header_v>() by the construction of the type.
>
> But this length field is coming from the firmware, correct? The guarantee is provided by firmware, not by Rust code calculating the length.
>
> Maybe Rust validating that the length matches, or is greater than or equal to, the message header would be one way to avoid doing the checked subtraction. I would still be comfortable doing the checked subtraction in case the firmware payload in the message buffer is corrupted and the length field is corrupted.
>
> I think Rust cannot trust fields coming from the firmware and needs to check them to prevent undefined behavior.
Right. The firmware is a separate code base, running on a separate
processor, and it is not part of the Rust driver. So it cannot
participate in any of the various Rust guarantees.
We should treat data that comes from the firmware as not yet
validated, external data.
Or maybe the policy is to include safety comments, like we do when
expecting C code to behave in a certain way. I
do not know. But we should identify the policy for this and stick to it
for future such issues.es
Yes. I've written above what I believe we should use for a policy.
thanks,
--
John Hubbard
next prev parent reply other threads:[~2025-12-15 2:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-21 15:00 [PATCH 0/4] gpu: nova-core: Fixups for GSP message queue and bindings Alexandre Courbot
2025-11-21 15:00 ` [PATCH 1/4] gpu: nova-core: bindings: Add missing explicit padding Alexandre Courbot
2025-11-21 15:00 ` [PATCH 2/4] gpu: nova-core: gsp: Fix length of received messages Alexandre Courbot
2025-12-12 7:59 ` Joel Fernandes
2025-12-12 8:10 ` Dirk Behme
2025-12-14 23:43 ` Alistair Popple
2025-12-15 1:22 ` Joel Fernandes
2025-12-15 2:46 ` John Hubbard [this message]
2025-12-15 2:47 ` Timur Tabi
2025-12-15 2:54 ` John Hubbard
2025-12-15 3:48 ` Alistair Popple
2025-12-15 3:37 ` Alexandre Courbot
2025-12-14 23:29 ` Alistair Popple
2025-12-15 3:41 ` Alexandre Courbot
2025-11-21 15:00 ` [PATCH 3/4] gpu: nova-core: bindings: Derive `MaybeZeroable` Alexandre Courbot
2025-11-21 15:00 ` [PATCH 4/4] gpu: nova-core: gsp: Replace firmware version with "bindings" alias Alexandre Courbot
2025-11-23 3:04 ` [PATCH 0/4] gpu: nova-core: Fixups for GSP message queue and bindings Alexandre Courbot
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=37cc2302-6a3d-4046-b28c-605221a67329@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=dirk.behme@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=epeer@nvidia.com \
--cc=gary@garyguo.net \
--cc=joelagnelf@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 \
/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®