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,
On Sat, Jun 10, 2023 at 11:13:28AM +0200, Stefan Dirsch wrote:
On Thu, Jun 08, 2023 at 08:13:32AM +0300, Andrei Borzenkov wrote:
On 08.06.2023 07:54, joeyli via openSUSE Factory wrote:
As you see, the kernel module verification will be enabled. So please sign your self-built kernel module.
mokutil --sb-state | grep -q "SecureBoot enabled" if [ $? -eq 0 ]; then privkey=$(mktemp /tmp/MOK.priv.XXXXXX) pubkeydir=/var/lib/nvidia-pubkeys pubkey=$pubkeydir/MOK-nvidia-driver-G06-525.116.04-8.1-$flavor.der
Should not NVIDIA (and any other external module) always generate and enroll certificate? Otherwise package installed when Secure Boot was temporary disabled will fail when Secure Boot gets enabled.
I strongly disagree. Question is: How many users are disabling SB temporary and how many permanently? Do we really want to annoy our users having disabled permanently SB with our wonderful Mokmanager interface after each driver upgrade or kernel update when boothing their machine although they don't need the new certificate at all?
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.
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. Hmm. Can we have a common scriptlet that can be triggered by YaST (or whatever) tool for managing that? Takashi