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