On Tue, Jun 13, 2023 at 03:18:16PM +0200, Takashi Iwai wrote:
On Tue, 13 Jun 2023 15:03:03 +0200, Michal Suchánek wrote:
On Tue, Jun 13, 2023 at 02:46:41PM +0200, Takashi Iwai wrote:
On Tue, 13 Jun 2023 13:10:53 +0200, Michal Suchánek wrote:
Hello,
As already said the status of --sb-state is irrelevant.
We have one place where the user expresses desire to use secure boot, and it's here:
/etc/sysconfig/bootloader:SECURE_BOOT="yes"
If that's yes, the platform supports secure boot, and it happens to be disabled, all the setup for making secure boot work should be done anyway.
If the user does not want to use secure boot ever they can change this setting. There is no other way to tell if the secure boot is disabled 'temporarily' or 'permanently' on a platform that does supporte secure boot.
... and we have one place where the user expresses desire to use secure boot *on the whole system*: BIOS setup. That wins over whatever OS sets up. And, the --sb-state option corresponds to it. Hence checking it makes sense, too, if your logic applies :)
That's not how it works. If you want to enable secure boot on an existing installation you first have to tell the system that you want to use secure boot so that it installs the signed grub image, and enrolls keys for any kernels and KMPs you install, and only then secure boot can be enabled in the BIOS.
Same if you want to test if an issue is related to the lockdown with secure boot - you disable secure boot in the BIOS but you don't want the unsigned grub or kernels and KMPs without enrolled keys if you intend to re-enable secure boot again.
Checking the --sb-state is another hidden variable for the user to track, for no good reason.
Well, how it works is irrelevant here; it's only the question which knob appears to be the major one ("we have one place....") But it'll be a waste of time to go further on this, so let's skip.
Well, if it does not work it's pointless
OTOH, it'd be certainly safer to deploy MOK no matter what value sb-state option has for avoiding the possible cases. So, it doesn't sound too bad to use /etc/sysconfig/bootlader:SECURE_BOOT as a checker instead of sb-state option -- as long as it's well documented.
Or, ideally, have a GUI to tweak this...
The secure boot setting can be changed on the installer summary page and inthe yast bootloader module. I think that's sufficient.
And that's the problem. The YaST bootloader module has no idea about the Nvidia setup.
So, having some check makes things broken if the setup is re-enabled: it's no matter whether --sb-state option check or /etc/sysconfig check. Neither triggers the (re-)deployment of Nvidia cert automagically.
OTOH, forcing MOK thingy at each time you update the kernel and nvidia packages *unconditionally* would be just XXXX (fill your favorite 4 letters). I'd switch to another distro if I would have to do it.
And it's not needed every time for the kernel because the certificate is enrolled only once per project from which you install a kernel, and not at all for the official release project. The problem is with the NVIDIA modules that are built locally every time with a new ephemeral key that needs to be enrolled on each update. IF the key was always the same it would need to be enrolled only once but we do not have secure storage for the key. Thanks Michal