On 8/27/25 1:47 AM, Alexandre Courbot wrote:
> 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.
I was wondering about the bounds themselves, though. Couldn't they
be wrong? (Do we care?)
>
> 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.
Yes, .checked_add() all over the place is just awful, would like to
avoid that for sure.
>
> 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?
Yes. And maybe even for Kangrejos.
thanks,
--
John Hubbard
