[Bug 1195118] New: some kernel modules cannot be loaded if secure boot is enabled
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 Bug ID: 1195118 Summary: some kernel modules cannot be loaded if secure boot is enabled Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: comes@naic.edu QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- If secure boot is enabled some modules provided by the -kmp- packages cannot be loaded. Example: modprobe vhba modprobe: ERROR: could not insert 'vhba': Key was rejected by service modprobe vboxdrv modprobe: ERROR: could not insert 'vboxdrv': Key was rejected by service modprobe pcfclock modprobe: ERROR: could not insert 'pcfclock': Key was rejected by service These are modules available since the release of 15.3 and for which no updates exist. Instead modules for which there exist updates can be loaded without error. Example: modprobe dlm modprobe ocfs2 modprobe gfs2 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 http://bugzilla.opensuse.org/show_bug.cgi?id=1195118#c1 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com --- Comment #1 from Takashi Iwai <tiwai@suse.com> --- As default, the kernel contains only its static built (SLE) cert and the ones passed from GRUB shim, and the error implies that the cert corresponding to your KMPs aren't included there. There are different builds of KMPs, a few of them are built with SLE, hence they work as-is. Others built from other OBS projects, including the official openSUSE:Leap:*, they won't work unless you install the corresponding cert on your system and enroll it via MOK manually. There is a brief description in the release notes. For Leap official KMPs, install openSUSE-signkey-cert package, if you didn't install it yet, reboot and enroll it at GRUB. Note that the trigger happens only once after installing this package. You can uninstall it, reboot, and re-install it, and reboot. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 http://bugzilla.opensuse.org/show_bug.cgi?id=1195118#c2 Giacomo Comes <comes@naic.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(comes@naic.edu) | --- Comment #2 from Giacomo Comes <comes@naic.edu> --- The package openSUSE-signkey-cert is already installed however mokutil --test-key /etc/uefi/certs/BDD31A9E-kmp.crt was telling that the key was not enrolled After running: mokutil --import /etc/uefi/certs/BDD31A9E-kmp.crt --root-pw I rebooted and enrolled the key. Now the modules can be imported. I assume that openSUSE-signkey-cert was installed during the OS installation, but when the machine rebooted, no one was in front of the console to enroll the new key. In my opinion this is a flaw of the openSUSE installation process. Once the installation process completes, the machine reboots and if no one is in front of the console the enroll process is missed and/or boot error messages as well. Fedora instead, after the installation process is completed, ask you to press a reboot button before continuing. I this way there is a person in front of the console when the machine reboots and he can take appropriate action if required. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 http://bugzilla.opensuse.org/show_bug.cgi?id=1195118#c3 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Kernel |Installation Assignee|kernel-bugs@opensuse.org |yast2-maintainers@suse.de QA Contact|qa-bugs@suse.de |jsrain@suse.com Severity|Normal |Enhancement --- Comment #3 from Takashi Iwai <tiwai@suse.com> --- On openSUSE, after the installation, the installer also asks for reboot in a dialog, too, but with a certain timeout. It has both merits and demerits. In anyway, this is more about the installation and enhancements. Reassigned. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 http://bugzilla.opensuse.org/show_bug.cgi?id=1195118#c5 --- Comment #5 from Giacomo Comes <comes@naic.edu> --- I did the following test installation on an UEFI machine and a virtual machine with secure boot enabled. The results are identical: I installed a KDE desktop. The package openSUSE-signkey-cert is installed automatically. After the installation completes and the machine reboots, there is no request to enroll the key present in openSUSE-signkey-cert and the command: mokutil --test-key /etc/uefi/certs/BDD31A9E-kmp.crt returns: /etc/uefi/certs/BDD31A9E-kmp.crt is not enrolled At this point you have to run: mokutil --import /etc/uefi/certs/BDD31A9E-kmp.crt --root-pw or zypper in --force openSUSE-signkey-cert then reboot and enroll the key. The release notes (section 4.1) are somehow incorrect: they assume that you have to manually install openSUSE-signkey-cert and after the reboot enroll the key. If I see that openSUSE-signkey-cert is already installed, I assume (incorrectly) that there is nothing more to do. If nothing else changes, at least the release notes should be updated. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 http://bugzilla.opensuse.org/show_bug.cgi?id=1195118#c6 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Release Notes |Installation Assignee|sknorr@suse.com |yast2-maintainers@suse.de QA Contact|lubos.kocman@suse.com |jsrain@suse.com --- Comment #6 from Takashi Iwai <tiwai@suse.com> --- Hrm, then indeed there must be some flaw in the installation process or cert packaging script. I tried by myself and found the same problem. In the zypper log, I found the lines: 2022-02-09 10:10:54|install|perl-libwww-perl|6.31-1.17|noarch||openSUSE-Leap-15.3-2|625baf3b98a428ca87c6a00193c31bf9e9fb63dfd6e74766fff1068a61144aa1| # 2022-02-09 10:10:55 openSUSE-signkey-cert-20210302-lp153.1.1.x86_64.rpm installed ok # Additional rpm output: # Failed to get root password hash # Failed to import /etc/uefi/certs/BDD31A9E-kmp.crt I guess that's the culprit? The package %post invokes mokutil --import "$cert" --root-pw and it seems accessing /etc/shadow and co. (Reassigned back to category Installation) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 http://bugzilla.opensuse.org/show_bug.cgi?id=1195118#c34 --- Comment #34 from Giacomo Comes <comes@naic.edu> --- I would like to add few comments about the installation hooks. The hooks are described in the link posted in comment 28. They are executed in the target system (chroot) but currently they are broken (if I'm not wrong, see boo#1195850). The link in comment 29 about embedding the hook itself in the control file refers to the DebugHooks library. Such hook is executed too in the target system (chroot), but the DebugHooks library has been removed since Leap 15.1. See boo#1132137 for more details. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 http://bugzilla.opensuse.org/show_bug.cgi?id=1195118#c35 --- Comment #35 from Michael Chang <mchang@suse.com> --- (In reply to Ancor Gonzalez Sosa from comment #33) [snip]
B) Modify grub2 to incorporate an extra step during its installation for importing the keys in case they are not all imported.
Does it have to always happen or an one-off thing during the last stage of installation process ? If it is on-off then I think yast hook is better.
C) Similar to (B) but in yast2-bootloader instead of in Grub2.
Maybe in shim-install ? As it is taking care MokManager installation. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 http://bugzilla.opensuse.org/show_bug.cgi?id=1195118#c43 --- Comment #43 from Joey Lee <jlee@suse.com> --- (In reply to Lukas Ocilka from comment #42)
Please, can anyone point me to the original feature request for the current implementation? It seems we are somehow stuck now.
You can reference bsc#1182641. The original feature request is after the SLE-Leap closing gap, some KMPs be signed by openSUSE signkey because they are in Leap repo but not in SLE. Those kernel modules can not be loaded by SLE-Leap kernel (closing gap) when secure boot is enabled. So, we need a package to help user to enroll openSUSE signkey to MOK when they want to use those Leap-only KMPs. But user doesn't know they need to install the signkey RPM. So I ask Max Lin's help to add it in installation pattern. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 http://bugzilla.opensuse.org/show_bug.cgi?id=1195118#c44 --- Comment #44 from Giacomo Comes <comes@naic.edu> --- (In reply to Joey Lee from comment #43)
(In reply to Lukas Ocilka from comment #42)
Please, can anyone point me to the original feature request for the current implementation? It seems we are somehow stuck now.
You can reference bsc#1182641.
I see something important in bsc#1182641 that's not there in the current implementation: | On the other hand, in the latest step of YaST installation. YaST should guide | user for what will user see after system first reboot. It should tell user that | a mok-manager UI will show up after reboot, and user can follow the mok-manager | UI to enroll openSUSE key to MOK. Right now, the user does not know that a enroll step is necessary after the first reboot. He can only guess it (if by chance he is in front of the monitor when the machine reboots). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 Petr Vorel <petr.vorel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |petr.vorel@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 http://bugzilla.opensuse.org/show_bug.cgi?id=1195118#c57 John <flsq6xoyf2@4o26j.anonbox.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |flsq6xoyf2@4o26j.anonbox.ne | |t --- Comment #57 from John <flsq6xoyf2@4o26j.anonbox.net> --- This is still an issue, after doing an upgrade it seems the openSUSE Secure Boot cert has changed. On reboot after the upgrade you get an enrollment prompt and it requests you to provide a password, which you can only guess. After failing several times I decided to boot without enrolling it and run mokutil -i /etc/uefi/certs/1F673297-kmp.crt set a password and reboot again to enroll it, this time knowing which password I have to provide. I don't understand why end users are required to do this instead of either having only one cert and everything signed with the same key or having both certs installed by default. This is not user friendly at all, it should "just work" without having to search on the internet why virtualbox fails to load a VM, possible causes, find out forum posts or bugs like https://bugzilla.opensuse.org/show_bug.cgi?id=1186784 then learn how to make enrollment requests on command line etc etc. It's really a pain and doesn't seem to be good practice.. This time I knew what to do, but many other users will probably have to spend a lot time to figure out why it doesn't work and what they have to manually do after a fresh install or upgrade... :( -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 http://bugzilla.opensuse.org/show_bug.cgi?id=1195118#c59 --- Comment #59 from John <flsq6xoyf2@4o26j.anonbox.net> --- (In reply to Marcus Meissner from comment #58)
the MOK dialog password is your systems root password.
Thanks. I tried the root password too and it didn't work. A possible reason are the special characters in my password, I have no idea if the unexpected blue enrollment screen demanding an unspecified password expects a US keyboard, I can't see what I type either since it only shows asterisks and there is no shell to type in and see if special characters are correct or what the equivalent key is. Also it isn't specified anywhere that it's the root password, are end users really expected to guess this? Is this really the desired design for openSUSE? I ask this after spending many hours months ago until I figured out why Virtualbox did no longer work after a fresh openSUSE 15.3 install, and after searching for the cause I see many other users had the same problem.. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195118 http://bugzilla.opensuse.org/show_bug.cgi?id=1195118#c60 Marcus Meissner <meissner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(meissner@suse.com | |) --- Comment #60 from Marcus Meissner <meissner@suse.com> ---
Also it isn't specified anywhere that it's the root password, are end users really expected to guess this? Is this really the desired design for openSUSE?
It is a problem with the kind of strict secure boot requirements and split-brain SUSE Linux Enterprise / openSUSE development in two entirely different environments. But it is something to review and think about to improve. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com