On Wed Aug 27, 2025 at 10:34 AM JST, John Hubbard wrote:
<snip>
>> + /// Returns the data payload of the firmware, or `None` if the data
>> range is out of bounds of
>> + /// the firmware image.
>> + fn data(&self) -> Option<&[u8]> {
>> + let fw_start = self.hdr.data_offset as usize;
>> + let fw_size = self.hdr.data_size as usize;
>> +
>> + self.fw.get(fw_start..fw_start + fw_size)
>
> This worries me a bit, because we never checked that these bounds
> are reasonable: within the range of the firmware, and not overflowing
> (.checked_add() for example), that sort of thing.
>
> Thoughts?
`get` returns `None` if the requested slice is out of bounds, so there
should be no risk of panicking here.
However, `fw_start + fw_size` can panic in debug configuration if it
overflows. In a release build I believe it will just happily wrap, and
`get` should consequently return `None` at the invalid range... Although
we can also get unlucky and produce a valid, yet incorrect, one.
This is actually something I've been thinking about while writing this
series and could not really decide upon: how to deal with operands and
functions in Rust that can potentially panic. Using `checked` operands
everywhere is a bit tedious, and even with great care there is no way to
guarantee that no panic occurs in a given function.
Panics are a big no-no in the kernel, yet I don't feel like we have the
proper tools to ensure they do not happen.
User-space has some crates like `no_panic`, but even these feel more
like hacks than anything else. Something at the compiler level would be
nice.
Maybe that would be a good discussion topic for the Plumber
Microconference?
