On 12/15/25 10:22 AM, Joel Fernandes wrote:
On Dec 15, 2025, at 8:43 AM, Alistair Popple <[email protected]> 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
