Removing duplication in /boot - affects kernel development

[Daniel Drake]

Hi,

I'd like to renew this thread, since we didn't get a great amount of
feedback last time. Also, one of the issues mentioned (but a little
downplayed) is the significance of removing the firmware updating code
from olpc.fth. Having stale code duplicated from the firmware in
olpc.fth bit us today with XO-4 development; the approach implemented
below would have avoided this problem. It would be nice if we could
land this before it bites again.

So, CCing various kernel developers, as this does affect kernel
development patterns a little. Will anyone be upset by the changes
proposed here?

On Mon, Mar 5, 2012 at 11:30 AM, Daniel Drake <dsd at laptop.org> wrote:
> Hi,
>
> At the moment, /boot in our images looks like this:
>
> Development builds - kernel is found at /boot/vmlinuz, initramfs at
> /boot/initrd.img and /boot/actrd.img. Unsecure boot is always used,
> meaning that olpc.fth is executed, which loads the kernel and
> initrd.img from those locations.
>
> Release builds - kernel is found unsigned at /boot/vmlinuz, unsigned
> initramfs are found at /boot/initrd.img and /boot/actrd.img. Those
> files are also signed and duplicated in actos.zip (and runos.zip which
> is a symlink), actrd.zip and runrd.zip. For unsecure boot, olpc.fth is
> used, loading the unsigned kernels. For secure boot, the signed zips
> are loaded by the firmware and olpc.fth is unused.
>
>
> The problem I'd like to solve here is that in our release builds, we
> are duplicating the kernel and initramfs (both unsigned and signed
> versions are both shipped).
> As a side effect of the solution outlined below, another small problem
> will be fixed: we currently duplicate the OFW code used to upgrade the
> firmware in olpc.fth, so that firmware updates take effect even in
> unsecure mode. We can remove this duplication too.
>
>
> The solution I'm proposing, with help from Mitch, is the following:
>
> Our builds will always ship the kernel and initramfs *only* in their
> actos/runos/actrd/runrd zip forms. However, in development builds,
> these zip files will not have a signature. This will be done by the
> build system - the build system will take the
> vmlinuz/initrd.img/actrd.img files installed by the kernel RPM, and
> put them in zip files (optionally with signatures), deleting the
> originals.
>
> olpc.fth (attached), used only in unsecure mode, by default will
> instruct the firmware to execute the system from the runos/runrd zip
> files, as if it were booting in secure mode, but without verifying any
> signatures. This also means that the standard secure boot code will
> upgrade the firmware if a newer version is found in bootfw.zip, so we
> can remove the duplicated firmware upgrade code from olpc.fth.
>
> This solves the duplication and is quite straight forward.
>
>
> The questions raised here relate to development. There are 2 common
> development routines that will be affected by this:
>
> 1. Installing a new kernel RPM to test a new kernel/initramfs before
> it gets shipped in a build (with rpm -Uvh kernel-foo.rpm).
> This will continue to install the new kernel as /boot/vmlinuz and the
> initramfs as /boot/{actrd,initrd}.img.
> The olpc.fth shipped as part of this change will look for the presence
> of /boot/vmlinuz, and, if found, will boot directly from that rather
> than looking in the zip files and executing the secure boot code as
> outlined above. So, this development routine is largely unchanged:
> install a new kernel RPM, copy the files to the right place (e.g.
> /bootpart, will probably try and improve on this step in future),
> reboot.
> The one side-effect that will happen here is that when you install a
> kernel RPM in this fashion, the automatic firmware upgrade from
> bootfw.zip will no longer happen. So, if you install a new kernel via
> a RPM, and then a new firmware via a RPM, the firmware won't be
> automatically flashed. I think we can live with this (and documented
> on the wiki), what do others think?
>
> 2. Copying a new kernel into place by hand (e.g. compile on another
> system, copy to /boot/vmlinuz on XO, reboot). This will no longer work
> as-is, since the system will now try to boot from /boot/vmlinuz (OK)
> and /boot/initrd.img (not found). The initramfs will have to be put in
> place at the same time as installing a custom kernel.
> I will add a "olpc-dev-kernel" script to olpc-utils which can simplify
> this (it will put /boot/vmlinuz and /boot/initrd.img in place by
> extracting them from the zip files). Run olpc-dev-kernel, *then* copy
> your test kernel over, and then things will work as before.
> (Similar considerations apply for initramfs development: if you drop a
> new initramfs in place, it won't be used until you put a /boot/vmlinuz
> kernel in place too. But, run olpc-dev-kernel first, and things will
> work as before).
>
>
> Are developers prepared to put up with these 2 minor changes in the
> interest in solving this duplication problem?
>
> Thanks,
> Daniel