Re: [PATCH] rust: add basic ELF sections parser
From: Danilo Krummrich
Date: Fri May 16 2025 - 12:02:28 EST
On Fri, May 16, 2025 at 11:35:42PM +0900, Alexandre Courbot wrote:
> On Fri May 16, 2025 at 10:35 PM JST, Danilo Krummrich wrote:
> > I think we should either we get to the conclusion that the desire of parsing (at
> > least part of) the firmware ELF is valid in the kernel and make it generic
> > infrastructure, or conclude that there really isn't a reasonable technical
> > reason to do that.
> >
> > Please let's work out the exact technical reasons for doing this in the kernel,
> > such that we can either conclude one or the other.
>
> I think it's mostly a matter of where we want to draw the line.
>
> We use ELF as a container format to associate binary blobs with named
> sections. Can we extract these sections into individual files that we
> load using request_firmware()? Why yes, we could.
>
> Now the GSP firmware for GA102 contains the following sections (skipped
> the ones that don't need to be extracted):
>
> [ 1] .fwimage PROGBITS 0000000000000000 00000040
> [ 2] .fwversion PROGBITS 0000000000000000 02448040
> [ 3] .fwsignature[...] PROGBITS 0000000000000000 0244804b
> [ 4] .fwsignature[...] PROGBITS 0000000000000000 0244904b
> [ 5] .fwsignature[...] PROGBITS 0000000000000000 0244a04b
> [ 6] .fwsignature[...] PROGBITS 0000000000000000 0244b04b
>
> That's 6 files instead of 1, for serving the same purpose. And the number of
> signatures is bound to *increase* as new chips get released, but since they are
> associated to chipsets, we can maybe limit them to the relevant chipset
> directory and limit the damage. Still it would clutter linux-firmware a bit
> more than it is today.
>
> But let's say we do this, and problem solved. Only... let's take a look at the
> booter binary, which is another innocent-looking firmware file.
>
> It includes a header with offsets to the code and data segments, that the
> driver loads into the falcon microcontroller. And one offset for the signatures
> that we need to patch. Reminds you of something? :) Should we split these ones
> too?
>
> I would push back really hard on that one, unless you agree to go after all the
> drivers that do the same thing (and I have names).
Great, but then why did you back off in your discussion with Greg? Given that
you are convinced that this is a valid thing to do for drivers, you should keep
discussing it with the target to make it common infrastructure.
I did not argue for or against it -- what I do disagree with is that we seem to
just agree to disagree and stuff a generic piece of code into nova-core after
three mails back and forth.
Please keep discussing the above with Greg until we get to a real conclusion.
- Danilo