On Sun, 2 Oct 2022 at 19:06, Antoine Damhet <antoine@xxxxxxxxx> wrote: > > On Sun, Oct 02, 2022 at 05:28:16PM +0200, Ard Biesheuvel wrote: > > On Sun, 2 Oct 2022 at 17:00, Antoine Damhet <antoine@xxxxxxxxx> wrote: > > > > > > Hello, > > > > > > Since `5f56a74cc0a6d9b9f8ba89cea29cd7c4774cb2b1`[1] I can't have both > > > SecureBoot enabled and lockdown disabled (I need to do that to allow > > > undervolting on my intel laptop). > > > > > > My current bootchain is: > > > > > > systemd-boot -> kernel+initrd+cmdline as a unified kernel image and > > > signed using a personal custom key. I don't use the shim loader. > > > > > > Until now I disabled the lockdown by setting the `MokSBState` + > > > `MokSBStateRT` UEFI variables to 1. Now they need to be volatile. > > > > > > > OK, so this means the patch works as intended: MokSBState is owned by > > shim, and you are not booting via shim, and so honouring those > > variables was a bug. > > > > > Would you be open to either add a variable or a command-line argument to > > > disable the kernel lockdown while keeping SecureBoot enabled ? > > > > Can't you just omit the lockdown LSM from your kernel build? > > It would probably work but I'm using a downstream Fedora build, I > would rather find a solution that would work in a default configure > state (eg: that distributions would be willing to use) if it's possible. > The distro kernels enable lockdown by default if secure boot is enabled, and the way to override that is to use shim and put it into insecure mode. So you have plenty of options here: - build your kernel without the lockdown LSM - use the distro kernel with shim - create a [signed] driver or uefi app that sets the volatile variable, and install it as a Driver### or SysPrep#### boot option Adding command line options or any other setting that is not signed and is persistent kind of defeats the purpose, so I don't see a point in adding support for that.
