On Mo, 20.10.25 16:29, Demi Marie Obenour ([email protected]) wrote: > > This is all anchored on the drive the firmware first boots from: > > systemd-boot searches for UKI on that drive, and then invokes the UKI > > from that drive. The UKI stub code than passes a reference to the > > drive to userspace via the StubDevicePartUUID EFI > > var. systemd-gpt-auto-generator in the intrd then uses that to find > > the rootfs + /usr. systemd-gpt-auto-generator then runs again after the > > transition onto the rootfs, where some additional mounts are searched > > for (i.e. /home/ + /srv/ and so on). This time it will look on the > > disk the rootfs/usrfs is located on. > > > > Once userspace is reached the reference to the backing disk is > > stabilized via the block device diskseq, hence should be somewhat safe > > regardig hot swapping different disks. The transition between EFI mode > > and Linux doesn't have a similar concept, hence it's not strictly > > protected against hot swapping different disks, it's hence essential > > that the entrypoint disks (i.e. rootfs + usrfs) are reasonably > > protected by other means (i.e. verity root hash and TPM binding) so > > that they cannot be swapped out. > > How does one bind the user data partition? A swapped out device can > have an identical rootfs.
As I said: bind the device to the TPM: as long as this is done properly it's very hard getting the system to accept a foreign disk as its own, because it cannot be unlocked via the TPM. > >> On some systems it is trivial, as the storage device it must be on > >> is known ahead of time. However, desktops and servers can have many > >> storage devices or even use RAID, making this very nontrivial. > > > > I am a strong believer that RAID should be used for user data, but > > *not* for the immutable OS itself. It's immutable after all, and > > guaranteed the same regardless where it's read from, as long as the > > root hash matches. > > Makes sense, except for servers where one needs to be able to boot > even in the event of a disk failure. Just maintain parallel copies of ESP/XBOOTLDR/rootfs on each disk, so that you can boot from any of them the same way, separately, not using RAID1. systemd currently won't help you much with it, but I'd be happy to take patches for this, if people care. I'd probably suggest introducing a new udev "tag" on block devices that indicates "parallel" root disks. Then, teach kernel-install + bootctl + systemd-sysupdate to operate on all devices tagged that way in addition to the actual current rootfs. Behaviour would be fully automatic then: as long as the root disks are properly tagged via udev rules they'd always be managed in sync. Lennart -- Lennart Poettering, Berlin
