Re: [PATCH] rust: add basic ELF sections parser

[Danilo Krummrich <dakr@kernel.org>]

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