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

[Tobias Hunger]

Hi Lennart,

thanks for taking the time to reply!

On Fri, Sep 5, 2014 at 6:58 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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.

Any place that you would care to recomend? It would suck to have each
distro put kernels somewhere else.

> 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

I want to be able to do atomic upgrades (like chromeos/coreos), so I need
to be able to give the root-subvolume (the system I want to boot) and the
usr-subvolume (the software configuration I want to boot).

I see that secure boot wants one file and that you will need to merge kernel
and initrd into one. But you will need the meta data to link the kernel/initrd
combo to a combination of root-subvolume and usr-subvolume. IIRC chromeos
also has that and stores that meta-data in non-volatile memory accessible to
the BIOS.

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

Nice ideal, but I do not see how that will work in general. You could bake some
id into the kernel (kernel version or whatever), but usually the kernel changes
slower than the sum of the files in /usr. You do want to boot different of these
usr-setups with one kernel.

> 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.

At this point the way the initrd is created seems more like an implementation
detail to me. But then I know too little about secure boot to know for sure.

My current problem is how to make my machine boot again with the kernel/initrd
I put into my usr-subvolume:-)

> 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...

That could work, provided there is something like a timestamp/version number
in /usr/lib/os-release that actually changes every time *anything* in
/usr changes
(or at least when those changes are getting distributed as an image).

You still need to store that information somewhere though for the kernel to know
what to boot.

> Hope that makes some sense?

Not really. I do see how this can work to boot the newest installation
of distroX: You
just need to look for the newest version of the usr-subvolume and boot that.

But how do I know which root-subvolume goes with that if there is more than one?

How do I boot the version I ran before the upgrade in case the upgrade failed?

I really do not see how you can get around storing meta-data somehow.

You can not change the kernel/initrd when it is signed, so you can not bake any
information into that file. You can apparently not have a separate
file when using
secure boot. That leaves EFI vars I think. Do those integrate with secure boot?

Anyway: For starters I would like to get the non-secure-boot case
rolling. A entry
for the boot loader with kernel command line settings does work there:-)

So how should the usr-subvolume be defined in that use-case?

Best Regards,
Tobias