Re: Supporting *multiple* bootloaders for arm64 on a single install?

[Stefan]

Hi Bengt!

> What form would a "firmware field" take?

In principle a gexp, which installs a firmware package, or #f. On x86 only #f 
is needed – unless you want Guix to install e.g. coreboot as your firmware.

> On principle, I am against boundless _incorporation_ of new dangerous 
> capabilities into a piece of software, as opposed
> to incoporating the ability to chain-load or otherwise encapsulate execution 
> of a single-purpose,
> minimal-source-for-better-inspection-and-exclusion-of-attacks-piece-of-software
>  that does something dangerous.

Well, GRUB has some nice features, which e.g. U-Boot hasn’t. It would be 
comfortable to use these features on other architectures than x86, too, e.g. 
graphics, modifying the kernel arguments, LUKS. Treating U-Boot as firmware 
makes GRUB the de-facto bootloader and brings ARM and other architectures on 
par with x86.

> ISTM UEFI is way more complicated than booting needs to be. What does the 
> boot process need to do besides
> (after post) identify a series of untrusted(!) block stream sources to try, 
> load the first image whose secure hash either matches
> a white list -- or securely display the hash of the unrecognized image and 
> ask authorized operator for ok + hash nickname
> for inclusion in the whitelist or reject? If ok, jump into boot image as 
> normal.
> 
> If a developer I trust says (in a securely communicated way) that I can 
> safely load something with a hash of whatever,
> I think that is more trustworthy than pretty much anything else I can think 
> of. And on a forum, someone else can say,
> "Don't trust that thing with hash xxx...zzz, it blew up for me," and I can 
> hold off until there's a consensus.
> 
> WDYT?

Chain loading U-Boot, iPXE and GRUB offers iSCSI capabilities, using the 
network driver from U-Boot, the TCP and iSCSI stack from iPXE, GRUB as the 
front-end¹ and iSCSI as block device for the OS. This enables possibilities you 
otherwise would not have. But of course this is not against your argument, that 
it gets more complex. But it offers new possibilities, which were not possible 
otherwise.

Anyway, I do not suggest to degrade U-Boot to be a firmware only, it can be a 
bootloader. But offering U-Boot as a firmware makes other architectures similar 
to x86, offering the same possibilities.

Actually I think any firmware to make GRUB usable is a good fit for a firmware. 
Using coreboot as firmware and GRUB as its payload is a good fit. If your 
system has a firmware capable to start GRUB, fine as well, nothing to do. If 
Guix needs to install a firmware first, before GRUB becomes usable, then I 
think there is a need for a firmware field. If you want to treat U-Boot as a 
firmware-and-bootloader, then use it as bootloader and omit the firmware field.

> BTW, why not build multiple installer ISOs targeted for different 
> architectures, and specialized needs?
> (for smaller ISOs and other benefits). I assume one could already do this 
> with guix, but why not leave the
> whole ball-of-wax to git clone, and let people with common architectures have 
> less to download and less
> irrelevant-to-them choices?

I think I don't understand what you are talking about here.


Bye

Stefan


¹ 
<https://fosdem.org/2020/schedule/event/firmware_duwu/attachments/slides/3867/export/events/attachments/firmware_duwu/slides/3867/Discover_UEFI_with_U_Boot_16_9.pdf>
 page 22