On Mo, 11.12.23 10:57, Lennart Poettering (mzerqung@xxxxxxxxxxx) wrote: > Which leaves item 1, which is a bit harder to address. We have been > discussing this off an on internally too. A generic solution to this > is hard. My current thinking for this could be something like this, > covering the UEFI world: support sticking a DDI for the main initrd in > the ESP. The ESP is per definition unencrypted and unauthenticated, > but otherwise relatively well defined, i.e. known to be vfat and > discoverable via UUID on a GPT disk. So: build a minimal > single-process initrd into the kernel (i.e. UKI) that has exactly the > storage to find a DDI on the ESP, and set it up. i.e. vfat+erofs fs > drivers, and dm-verity. Then have a PID 1 that does exactly enough to > jump into the rootfs stored in the ESP. That latter then has proper > file system drivers, storage drivers, crypto stack, and can unlock the > real root. This would still be a pretty specific solution to one set > of devices though, as it could not cover network boots (i.e. where > there is just no ESP to boot from), but I think this could be kept > relatively close, as the logic in that case could just fall back into > loading the DDI that normally would still in the ESP fully into > memory. BTW, one thing I would like to emphasize though. i think this item is really the last thing you should focus on. If your OS never transitions out of the initrd, and gets its payload merged in via DDIs, then the root fs should be reasonably small enough and "fully used at boot" (i.e. every sector read anyway) that doing this extra work of finding a split-out DDI on the ESP is entirely unnecessary and just a waste of time (both of developer time and boot time). Lennart -- Lennart Poettering, Berlin
