For the last couple of years I've been rolling my own kernels on a
couple of machines in order to have better support for secure boot and
especially mok keys. This has been necessary for being able to boot with
lockdown=confidentiality/integrity and still be able to load any signed
out-of-tree (dkms) modules. The official kernels in arch is built
without IMA support as it would break the ability to kexec to another
kernel when secure boot is on (since the kernels are built with
auto-generated keys, they would fail validation). There are some bug
reports on the subject, see [1] and [2].
How I'm validating signed out-of-tree modules goes as following:
- uefi to setup mode
- create my own EFI keys, and enroll them
- roll my own uki kernel (built with IMA) and sign it and it's modules
and any out-of-tree modules
- set uefi to boot shim.efi, which then calls grubx64.efi (which is just
a renamed systemd-boot in my case)
- shim passes on mok keys
- systemd-boot boots the kernel with lockdown=confidentiality
- kernel adds the keys passed from shim to the (.machine) keyring and
successfully loads any modules signed with a key listed in mok
It's been a while since I set it up so I might have misremembered some
step there.
Anyway to my question, since the situation with kexec and IMA is
probably not going to change, and since there probably (?) are more
people out there who would like to use the whole secure boot chain with
MOKs and all, perhaps it would be possible to discuss providing another
official kernel which is built to support the above scenario? I'm not
too deep into the arch dev system and tools, but considering what I'm
doing - just pulling the PKGBUILD and doing some minimal changes to the
config and then building it, it seems it would not add too much of a
maintenance overhead.
Perhaps there are other ways of achieving the same results that I'm not
aware of.. if so I'm curious to hear about it. Mostly I'm just trying to
get out of having to use custom kernels. :-)
Thanks for reading,
Johan
[1] https://bugs.archlinux.org/task/75102
[2] https://bugs.archlinux.org/task/75041
