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

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, May 30, 2025 at 11:34:02PM +0900, Alexandre Courbot wrote:
> On Fri May 30, 2025 at 6:01 PM JST, Greg KH wrote:
> > On Fri, May 30, 2025 at 03:59:03PM +0900, Alexandre Courbot wrote:
> >> On Fri May 30, 2025 at 3:22 PM JST, Greg KH wrote:
> >> > On Fri, May 30, 2025 at 09:58:02AM +0900, Alexandre Courbot wrote:
> >> >> However, Nova also supports a couple of older chip generations that use
> >> >> the same GSP firmware -  it is for these that the ELF unpacking must
> >> >> occur in the kernel. IIUC this has to do with the capabilities of the
> >> >> microcontroller that ultimately does the loading (more capable RISC-V on
> >> >> Hopper+ vs. older and more limited Falcon).
> >> >
> >> > Why specifically does the kernel have to get involved here?  What
> >> > requires it to do it that userspace can not?
> >> 
> >> I don't know of a user-space tool that is readily available and could
> >> perform such extraction of the ELF content upon kernel request. Is there
> >> anything like this?
> >
> > libelf provides you with the needed tools for this.
> >
> > And you didn't answer my question.
> 
> Yes, extracting a section of an ELF file is as trivial as calling
> objcopy, no issue with that.

Great!

> What I don't understand is, who calls objcopy to do that in the first
> place, when, and how is the extracted section passed to the kernel?
> After digging a bit I found out about CONFIG_FW_LOADER_USER_HELPER which
> looks like it could help, but that option is disabled even on my Arch
> stock kernel.

Yes, userspace is the thing that does this when it is told to do it by
the kernel.

> But even assuming it was readily available, how to use it is not clear
> to me and I could not find a single actual example. I assumed a udev
> rule could catch the uevent and call a script that extracts the section
> and load it through the sysfs loading interface, but
> fallback-mechanisms.rst mentions that "...however firmware loading
> support was removed from udev as of systemd commit be2ea723b1d0". Which
> makes this idea look like a dead-end.

Look at how all firmware is loaded on your system today, this isn't a
new thing, it's been working well for everyone for decades now :)

> So to try to answer your question, I am not disagreeing that userspace
> is capable of doing what we currently do in the kernel. My follow-up
> questions to that are: how do we command userspace to do that work for
> us when we request the firmware, how do we provide the result to the
> kernel, and is this something that distros can adopt easily? I'm happy
> to consider doing things this way, but would need a few pointers to look
> into.

Again, look at how your firmware for your devices in your laptop are
loaded today.

thanks,

greg k-h