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

[Bengt Richter <bokr@bokr.com>]

Hi Stefan, et al,

On +2021-06-19 17:11:45 +0200, Stefan wrote:
> Hi!
> 
> >> But as I understand it, guix only supports a single bootloader entry. 
> > 
> > That is correct.
> > 
> >> To support all of the above, I would need three separate bootloader
> >> instances... one for Pinebook, one for Pinebook Pro, and lastly a
> >> grub-efi bootloader.
> > 
> > Stefan wrote a Guix chain bootloader that is in master--but it's meant
> > to be only used for bootloaders where there is a primary "bare-metal-loaded"
> > bootloader and the others are chain-loaded one-after-another from ONE filesystem
> > (for example Raspberry Pi and/or EFI bootloaders).
> > 
> > (It's currently used in order to use an EFI bootloader hosted on NFS--which
> > is an awesome way to manage embedded boards)
> > 
> > The chain bootloader itself is one Guix bootloader.
> > 
> > I advise you to search for mails by Stefan on the guix-devel mailing list--those
> > are very illuminating.
> 
> By the way, there is <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48314> since a month meanwhile, which now makes the support for the Raspberry Pi complete. The same bootloader can be used for an NFS root installation and an installation on micro SD card or an USB drive by just changing the mount point of the root file-system.
> 
> Danny, I’d appreciate your review very much. This time you can apply the patches and just use the gnu/system/examples/raspberry-pi-64.tmpl with guix system init. :-) 
> 
> >> And somewhere along the way I've lost track of how we get to
> >> install-pinebook-pro-rk3399-u-boot…
> 
> The same happened to me. I’ll first wait for the patch #48314 to be accepted, before I’ll look again into creating a disk image for the Raspberry Pi.
> 
> > If you do want to chainload grub-efi eventually, that's supported in Guix master,
> > see "efi-bootloader-chain".  It's meant for the end user to be able to use.
> 
> Referring to the patch #48314, the efi-bootloader-chain got simplified. It basically prepares a profile with all files to be copied as is, no special “collection” folder any more. And the installer of the grub-efi-netboot-(removable-)bootloader is now merely a simple “(copy-recursively bootloader-profile)“ procedure.
> 
> >> A related idea would be to generate an EFI bootable image with
> >> sufficient emtpy space before the first partition (16MB) and then one
> >> could manually install the appropriate u-boot, maybe with some helper
> >> scripts to avoid having to do it completely manually...
> > 
> > Yeah, that's possible right now.  After all, you don't have to load the generated
> > guix system disk image on bare metal.  Just boot it in qemu and install u-boot
> > there for example.  Or even edit the image manually by using dd.  (unfortunately,
> > on almost every ARM system I set up Guix on so far, one or both of those were
> > necessary)
> 
> I believe that the ARM future is UEFI, like on PCs. A lot of distributions already chainload U-Boot and GRUB an arm systems. There is a specification for ARM servers which demands UEFI¹. And there is even the choice between U-Boot and TianoCore/EDK II.
> 
> I think meanwhile that it would be beneficial, if, beside a bootloader field, Guix would accept an optional firmware field. Then the U-Boot or TianoCore/EDK II (or coreboot) could become some board specific firmware, and the actual bootloader would be grub-efi installed on an EFI System Partition. For systems like the Raspberry, which require their firmware on a FAT partition, there is the already working efi-bootloader-chain solution.
> 
> The firmware could only be installed on explicit request. It's not expected to see frequent changes – every re-installation is a risk to brick the system. (For my taste the bootloader is re-installed too often already.)
>

What form would a "firmware field" take?

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.

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?

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?

> 
> Bye
> 
> Stefan
> 
> 
> ¹ <https://documentation-service.arm.com/static/5fb7e415d77dd807b9a80c80>

-- 
Regards,
Bengt Richter