Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

Fri Jun 21 17:35:18 CEST 2024

On June 21, 2024 thus sayeth Simon Glass:
> Hi Peter,
> 
> On Fri, 21 Jun 2024 at 01:35, Peter Robinson <pbrobinson at gmail.com> wrote:
> >
> > On Fri, 21 Jun 2024 at 00:05, Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hi Nishanth,
> > >
> > > On Thu, 20 Jun 2024 at 15:35, Nishanth Menon <nm at ti.com> wrote:
> > > >
> > > > Hi Team,
> > > >
> > > > We have briefly discussed this topic on IRC[1]. I would like to
> > > > propose a new boot-firmware repository similar to the Linux-firmware
> > > > repository under the aegis of u-boot hosting.
> > > >
> > > > In addition to TI, it looks like some NXP[2] and Rockchip[3]
> > > > platforms seem to require additional closed-source/open-source
> > > > binaries to have a complete bootable image. Distribution rights and
> > > > locations of these binaries are challenging, and there needs to be a
> > > > standard for how and where they are hosted for end users.
> > > >
> > > > Further, looking ahead to future architectures:
> > > > * IP firmware: More and more IP vendors are embedding their own
> > > >   "specialized controllers" and require firmware for the operation
> > > >   (similar to Rockchip's DDR controller, I guess),
> > > > * boot stage firmware: Additional stages of the boot process involve
> > > >   vendor intermediate firmware, such as power configuration.
> > > > * Security enclave binaries: While I see a few folks trying to have an
> > > >   open-source s/w architecture, many PKA and PQC systems still require
> > > >   prop binaries for IP reasons.
> > > >
> > > > NOTE: I am not judging any company(including TI) for reasons why some
> > > > firmware is proprietary, but I hate to have the end users and other
> > > > system (distro) maintainers have to deal with hell trying to make the
> > > > life of end users easy to live with.
> > > >
> > > > In the case of TI's K3 architecture devices, we have two binary blobs
> > > > that are critical for the boot process.
> > > >
> > > > 1. TIFS Firmware / DMSC firmware[4]—This is the security enclave
> > > >   firmware. It is often encrypted, and sources are not public (due to
> > > >   various business/regulatory reasons).
> > > > 2. DM Firmware[5] - There is a source in public in some cases and
> > > >   binary only in others - essentially limited function binary to be
> > > >   put up in the device management uC. In cases where the source is
> > > >   available, the build procedure is, in my personal opinion, pretty
> > > >   arcane, and even though in theory it is practical, in practice, not
> > > >   friendly - efforts are going to simplify it, even probably integrate
> > > >   it with a more opensource ecosystem, but that is talking "look at the
> > > >   tea leaves" stuff.
> > > > 3. Low Power Management (LPM) binaries: tifs stub: another encrypted
> > > >   binary that gives the tifs system context restore logic before
> > > >   retrieving tifs firmware and a corresponding DM restoration binary.
> > > >
> > > > All told, this is not unlike the situation that necessitated the
> > > > creation of a Linux firmware repository.
> > > >
> > > > Options that I see:
> > > >
> > > > 1. Let the status quo be - SoC vendors maintain random locations and
> > > >   random rules to maintain boot firmware.
> > > > 2. Ask Linux-firmware to host the binaries in a single canonical
> > > >   location
> > > > 3. Host a boot-firmware repository - u-boot repo may be the more
> > > >   logical location.
> > > >
> > > > * (1) isn't the correct answer.
> > > >
> > > > * (2) Though I haven't seen any policy from the Linux-firmware
> > > >   community mandating anything of the form, the binaries we are talking
> > > >   of may not belong to Linux-firmware as they aren't strictly speaking
> > > >   something Linux kernel will load (since the bootloader has that
> > > >   responsibility), and in some cases may not even directly talk to
> > > >   (security enclave or DDR firmware stuff). I am adding Josh to this
> > > >   mail to see if he has any opinions on the topic (but keeping
> > > >   from cross posting on linux-firmware list, unless folks feel it is
> > > >   OK).
> > > >
> > > > On (3):
> > > > Proposal:
> > > >
> > > > * Create a boot firmware repository in Denx and/or GitHub (if
> > > >   financials are a hurdle, I hope we can solve it as a community).
> > > > * Limit binaries only to those consumed part of the u-boot scope.
> > > >
> > > > * Limit binaries only to those that do not have an opensource project
> > > >   (Trusted Firmware-A/M, OP-TEE, etc..) or depend entirely on vendor
> > > >   source or are binary only in nature (subject to licensing terms below)
> > > > * Limit binaries to some pre-established size to prevent repository
> > > >   explosion - say, 512Kib?
> > > > * Follow the same rules of integration and licensing guidelines as
> > > >   Linux-firmware[6].
> > > > * Similar rules as Linux-firmware guidelines of ABI backward and
> > > >   forward compatibility.
> > > > * Set a workflow update flow and a compatibility requirements document
> > > >
> > > > If we agree to have boot firmware under the stewardship of u-boot, we
> > > > should also set other rules, which is excellent to discuss.
> > > >
> > > > Thoughts?
> > >
> > > I suggest:
> > >
> > > 4) Add a 'binman blob' subcommand which can fetch blobs, similarly to
> > > how 'binman tool -f xxx' features a tool, using the image description
> > > to know what is needed and some configuration for where to find it /
> > > how to build it.
> >
> > This is a solving a different problem IMO. Also most distros build in
> > constrained environments so pulling FW randomly with a tool in the
> > build process won't work. Also most users won't want to pull the
> > latest each time they build, most vendors will choose a static set of
> > versions and only bump to deal with bugs, CVEs or explicit features
> > they need rather than having a series of moving targets.
> 
> Yes of course. This is actually how 'binman tool' works - unless you
> explicitly fetch something it uses what you have. I am certainly not
> suggesting that binman fetch things as part of the build itself, but
> that it provide a way to programmatically obtain the required bobs,
> e.g. fetching from a defined (or public) repo or building from source.
> We would need to support different versions of the same file, dealing
> with files which are common across SoCs, etc.
> 
> >
> > Well the whole point of the repo is to remove the guesswork, it would
> > be a set of firmware that is expected to work in a single location.
> 
> I don't believe a repo is sufficient. The instructions for building
> images are becoming complex enough that it is a non-trivial job for
> anyone to work through the steps and figure out what to do. If you are
> deeply into a particular SoC it is worth the effort, I suppose. But I
> favour a comprehensive image description (as provided by Binman) and a
> programmatic method.
> 
> I'm not sure of the best way to 'uprev' blobs, but wherever they are
> stored, I suppose the image description would be changed to select the
> new version.
> 
> >
> > > IMO the actual repo is not the ultimate goal here. Building and
> > > testing should be the ultimate goal.
> >
> > I disagree, the repo would assist working and tested firmware because
> > there could be a review/test process as part of it to ensure things
> > work and are tested to give users a good experience rather than having
> > to search the web and forum posts to attempt to find pieces that work
> > together.
> 
> I believe we are saying the same thing here, albeit that I feel a repo
> is not enough.
> 

So long as we can keep the 'binman blob' a separate step. I agree that 
we can do much better than a signed git repo and we should at the very 
least try this out before we go down the linux-firmware route. But many 
build systems (like buildroot) have different download, build, and 
install phases and people get upset when we mix them (python, rust)

~Bryan

>
> Regards,
> Simon
> 
> 
> >
> > > >
> > > > [1] https://libera.irclog.whitequark.org/u-boot/2024-06-13#36498796;
> > > > [2] https://docs.nxp.com/bundle/AN14093/page/topics/build_the_u-boot.html
> > > > [3] https://bbs.t-firefly.com/forum.php?mod=viewthread&tid=2236
> > > > [4] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-sysfw?h=ti-linux-firmware
> > > > [5] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-dm?h=ti-linux-firmware
> > > > [6] https://docs.kernel.org/next/driver-api/firmware/firmware-usage-guidelines.html
> > > > --
> > > > Regards,
> > > > Nishanth Menon
> > > > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D