[RFC] proposal for refactoring bootloaders

[RFC] proposal for refactoring bootloaders

[Lilah Tascheter]

hi everyone!

I've been working on submitting to mainline some bootloaders I
packaged a while ago on my channel (an efi-stub bootloader supporting
secure boot & full disk encryption and p-boot for pinephones) and came
across a good few hard points in how guix handles bootloaders. the
current system seems to have been made with only grub/extlinux-alikes
in mind, and makes working with everything else extremely cumbersome
and incompatible with generation rollbacks. before I start
making/submitting changes, I wanted to ask for opinions on the following
plan:

* merge bootloader-installer and bootloader-disk-image installer.
  almost all cases where one is used, the other is called with almost
  the exact same arguments, except for in (gnu system image), which
  provides the image itself. this should be provided in general; BIOS
  bootloaders and u-boot need to know the main disk device anyway.

* create a new bootloader-config-installer record field
  (accepting a gexp), replacing bootloader-configuration-file and
  bootloader-configuration-file-generator. it's really only
  grub/extlinux-alikes that use a single, static-path config file. uefi
  configuration involves calling efibootmgr, and p-boot needs an entire
  configuration partition. can provide a helper procedure to replicate
  current behavior, and register the gexp as a gc root to prevent gc of
  boot objects, in lieu of the current behavior.

* provide the full bootloader-configuration record to
  bootloader-installer instead of just bootloader-package. the full
  record is available every time bootloader-installer is called.

* don't provide bootloader-configuration to bootloader-config-installer.
  reinstall-bootloader (guix scripts system) regens the configuration
  without access to the full bootloader-configuration record.
  conceptually, config install should only affect the boot entries
  themselves anyway.

* change initialize-efi-partition (gnu build image) to handle any
  bootloader-installer when used, providing its partition as the target.
  also un-hardcode grub in system-disk-image (gnu system image).

* to facilitate secure boot support, add a
  bootloader-configuration-signing-keypair record field accepting a pair
  of out-of-store paths to encryption keys.

* provide generation numbers to bootloader-installer and
  bootloader-config-installer, to help with coordination between the
  procedures, and bootloader-config-installer allowing incremental
  rollbacks in bootloaders that have to copy the kernel/initrd off-root.

(thanks Hilton Chain for initial discussion on this in the uefi support
patch thread!)

- lilah

Re: [RFC] proposal for refactoring bootloaders

[Lilah Tascheter]

one more quick change that I've realized will be necessary: add a
bootloader-targets field to boot-parameters. some bootloaders would
need target info to know where to install config files, and
reinstall-bootloader doesn't have access to the operating-system
record. rollbacks to generations pre-field addition shouldn't be an
issue with this either, as existing bootloaders (sans depthcharge?) do
just fine without targets.

all in all, bootloader-installer and bootloader-config-file-installer
would be procedures that return gexps, with the following signatures:

* (installer entries #:key bootcfg mount-offset generation old-entries
   store-crypto-devices store-directory-prefix locale)
* (config-file-installer entries #:key package targets mount-offset
   generation old-entries store-crypto-devices store-directory-prefix
   locale)

mount-offset is the current target, and old-entries becomes an alist with
generation numbers.

- lilah

Re: [RFC] proposal for refactoring bootloaders

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

On Fri, Feb 16, 2024 at 02:33:02AM -0600, Lilah Tascheter wrote:
> one more quick change that I've realized will be necessary: add a
> bootloader-targets field to boot-parameters. some bootloaders would
> need target info to know where to install config files, and
> reinstall-bootloader doesn't have access to the operating-system
> record. rollbacks to generations pre-field addition shouldn't be an
> issue with this either, as existing bootloaders (sans depthcharge?) do
> just fine without targets.
> 
> all in all, bootloader-installer and bootloader-config-file-installer
> would be procedures that return gexps, with the following signatures:
> 
> * (installer entries #:key bootcfg mount-offset generation old-entries
>    store-crypto-devices store-directory-prefix locale)
> * (config-file-installer entries #:key package targets mount-offset
>    generation old-entries store-crypto-devices store-directory-prefix
>    locale)
> 
> mount-offset is the current target, and old-entries becomes an alist with
> generation numbers.

The current bootloader system started as grub only and then grew more
capabilities for other things too.  It should be possible to flash
u-boot separately and then use grub-efi (or something like it) but it's
not currently supported out of the box.  I look forward to seeing how
this might look.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC] proposal for refactoring bootloaders

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Lilah,

On Fri, Feb 16, 2024 at 02:33:02AM -0600, Lilah Tascheter wrote:
>
> one more quick change that I've realized will be necessary

I made some changes to my bootloader locally and believe the commit
series here [1] could be useful to you. It removes a lot of the
confusion that arises when the boot-parameters are rewritten on the fly.

Kind regards
Felix

[1] https://debbugs.gnu.org/69343