[systemd-devel] So how am I supposed to put together my Linux system?

[Lennart Poettering]

On Fri, 05.09.14 16:19, Tobias Hunger (tobias.hunger at gmail.com) wrote:

> Hi
> 
> I have read http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
> with interest and since I am using a home-grown image based
> installation scheme anyway, I would like to try and move that closer
> to the proposal from the systemd cabal. It is pretty easy to create
> the suggested subvolumes, but I how to proceed from that point still
> is a bit unclear to me:-)
> 
> How should I install kernels/initramfs though?
> 
> I understood the plan to be to copy the kernel/initramfs into the EFI
> boot partion and to create boot loader entries linking the
> kernel/initramfs combo with the root file system.
> 
> But where do those kernels come from? I would think the usr-subvolume
> is the best place for that. Did you recommend a place for the
> kernel/initramfs yet (E.g. <usr-subvolume>/boot) or do you expect the
> distributions to decide that?

Yeah, we want to encourage distros to install kernels into /usr,
somewhere next to where the kmods already are, and then copy that over
where necessary into the used boot partition. We actually have sime
infrastructure for this in place in systemd, in the "install-kernel"
script, which also has a man page.

> Do you consider a tool that will copy the kernel/initramfs from the
> usr-subvolumes into the EFI boot partition in scope for systemd or
> should the distributions handle that instead? I think the following
> steps are pretty generic and could be handled by a small tool shipped
> as part of systemd:
> 
> * iterate over the usr-snapshots and get the kernel(s) and initramfs
> file(s) from all the snapshots boot directory (assuming you expect the
> distributions to put the kernels into /usr/boot).
> 
> * copy those into the EFI boot partition. De-duplicate them while
> doing that. EFI boot partitions are FAT-based, so that will most
> likely require a bit of hashing as FS-based deduplication and
> hard-/softlinks are out:-)
> 
> * create the necessary boot loader entry files according to the
> http://freedesktop.org/wiki/Specifications/BootLoaderSpec/
> 
> I need to give the root filesystem/subvolume with the usual kernel
> command line arguments, so that is not a problem. But how should the
> usr-subvolume be specified? Setting that in the root-subvolume makes
> little sense and the initramfs needs to mount /usr anyway, so I guess
> that will require more kernel command line arguments. Did you define
> those yet? I would suggest just using usrfs, usrflags and usrfstype
> (where the usrfs should default to rootfs and usrfstype to btrfs).

I think in the long run we really need to get to something where we
easily can cover a mode similar to chromebooks, where we have a fully
verified trust chain from the firmware to the apps we run on the
OS. (Not saying that this is how developers and folks will use the
stuff by default, but a large number fo setups will take benefit of it
I am sure). Now for the trust chain to work, the secureboot firmware
stuff would sign a kernel image. This kernel image would need the
initrd appended, so that it can also be covered, and it would need to
know its own identify, and then search for a btrfs volume, and for a
volume that matches precisely what the kernel's identity is. The btrfs
subvolume would carry verification data then, and the chain goes on
from there.

This of course means a couple of things: 

1. we can only really have one file per boot menu entry, not three
anymore as we have right now (for kernel + initrd + meta info for the
cmdline and stuff), because we need the firmware to verify it and
having external config files then is really hard to do

2. If we cannot have external config files, then kernel/initrd should
find their stuff an empty kernel cmdline option.

3. As the signature on the kernel/initrd needs to come from the vendor
we cannot build the initrd on the final system anymore, but need to
support vendor-built initrds. Or in other words, the vendor would
simply supply some file in /usr somewhere which is already the
combined version of kernel and initrd, properly EFI signed, and we
would then just copy that into the ESP after each upgrade.

4. The initrds should probably use information from
/usr/lib/os-release (as shipped in the initrd as a copy of the OS'
version) to build the btrfs sub-volume name to boot from. It should
not allow overriding this name via the kernel cmdline, at least as
long as we are in a mode where secureboot is actually turned on...

Hope that makes some sense?

Lennart

-- 
Lennart Poettering, Red Hat