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

[Bengt Richter]

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