mkosi
mkosi copied to clipboard
systemd
Separate boot partition when using BIOS booting
(Originally brought up in https://github.com/systemd/mkosi/pull/489#issuecomment-795469878)
Currently mkosi does not support BIOS boot when gpt_squashfs is used. Furthermore, when BIOS booting is used with --verity enabled, dm-verity is not used at all: no roothash is passed on the kernel command line, and hence systemd won't set up the device: the root partition is used as-is. Indeed, since grub.cfg is created on the very block device for which integrity will be validated, this is impossible.
I believe this could be worked around if, similar to the ESP for UEFI boot, a separate /boot partition would be used in the GPT image. Using this approach, a roothash could be injected in grub.cfg after the dm-verity data has been calculated. It would also allow for a SquashFS root partition to be used (I believe).
Of course, this implies the kernel and initrd (and whatever else sits in /boot) doesn't fall under dm-verity validation, but the Grub wouldn't check/use these checksums anyway.
(What would be really neat is if we could simply use root=gpt-auto, even with BIOS boot, but from what I understood systemd doesn't support this in non-UEFI environments.)
Of course, this implies the kernel and initrd (and whatever else sits in /boot) doesn't fall under dm-verity validation, but the Grub wouldn't check/use these checksums anyway.
This is the same when using an ESP right? If so, it's not a problem.
This generally looks OK to me but needs some specifics cleared out like which partition do we put grub on? Can we reuse the XBOOTLDR partition for this?
Of course, this implies the kernel and initrd (and whatever else sits in /boot) doesn't fall under dm-verity validation, but the Grub wouldn't check/use these checksums anyway.
This is the same when using an ESP right? If so, it's not a problem.
Indeed.
This generally looks OK to me but needs some specifics cleared out like which partition do we put grub on? Can we reuse the XBOOTLDR partition for this?
Putting this on XBOOTLDR would make sense as far as I'm concerned (would put the grub2 directory under /boot/grub2 as seen from the host, which is quite 'standard'). However, XBOOTLDR is, as far as I'm aware, currently an optional partition, which should then change.
I don't particularly mind making XBOOTLDR required when using grub. Any idea how backwards compatible this would be? If the grub files are still accessible at the same paths, I think we can do this by default instead of putting it behind an option.
Going through the Boot Loader Specification and what systemd-gpt-auto-generator does with the XBOOTLDR partition, it appears to me using said partition for this purpose is fine and as designed.
However, what systemd-gpt-auto-generator does may not matter much anyway because this is for BIOS based systems which it doesn't support :wink:
Yeah, let's use XBOOTLDR for this. Only thing I'm unsure about is whether we should do this unconditionally or not. I'm not familiar enough with grub to know whether we'd break any important use cases by doing this or not. I think we can get away with automatically enabling XBOOTLDR for BIOS setups and installing grub there. If users complain (or if we figure out it breaks some important use case), we can see about making it configurable.
I haven't had time to work on this, however still very interested in the feature.
One more thought: instead of injecting the roothash in grub.cfg, we could write it in some file (next to grub.cfg) which is source'd by Grub (instruction in grub.cfg) and used as a variable where applicable. Rationale for this: we're building a systen where we want to use mkosi-built images both as the boot disk (e.g., flashed on a USB-stick), as well as using a loop-device from a Grub installed on the host machine (fetching the kernel and initrd images out of the disk image using Grub's loopdev functionality). If at that point we can also source this file containing the roothash (and ignore the grub.cfg from the disk image altogether), this would make things a lot easier.