[Bug 1190261] New: Kernel scriptlets: XXX: Only call mokutil if UEFI and shim are used
https://bugzilla.suse.com/show_bug.cgi?id=1190261 Bug ID: 1190261 Summary: Kernel scriptlets: XXX: Only call mokutil if UEFI and shim are used Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: martin.wilck@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Spin-off from bug 1189841. From https://github.com/openSUSE/suse-module-tools/pull/33: @mwilck: so why not test this? e.g. like this: if [ "$(mokutil --sb-state 2>/dev/null)" = "SecureBoot enabled" ]; then ... fi @hramrach: ??? The part that github displays as context for this comment does not look relevant @hramrach hramrach 21 hours ago Member Right, if you refer to XXX: Only call mokutil if UEFI and shim are used then I have no opinion on that. Should be probably handled in a separate bug and the implications of any possible check discussed to death. @hramrach hramrach 21 hours ago Member Actually, there is the problem that on arm64 you suddenly get from no shim to shim on SP update without any warning so this is really hairy to get right. Really deserves a separate bug. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190261 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msuchanek@suse.com QA Contact|qa-bugs@suse.de |martin.wilck@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190261 https://bugzilla.suse.com/show_bug.cgi?id=1190261#c1 Jiri Slaby <jslaby@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jslaby@suse.com, | |martin.wilck@suse.com Flags| |needinfo?(martin.wilck@suse | |.com) --- Comment #1 from Jiri Slaby <jslaby@suse.com> --- I quite don't understand what this is about? Should be kernel scripts updated? Or SMT's? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190261 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|kernel-bugs@opensuse.org |martin.wilck@suse.com Flags|needinfo?(martin.wilck@suse | |.com) | -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190261 https://bugzilla.suse.com/show_bug.cgi?id=1190261#c2 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jlee@suse.com Flags| |needinfo?(jlee@suse.com) --- Comment #2 from Martin Wilck <martin.wilck@suse.com> --- Joey, is it possible to use mok-manager to import certificates in DB if secureboot is disabled? If it isn't, we could skip the mokutil step in that case. Or would it make sense to enroll the certs anyway, just in case SB is enabled at a later time? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190261 https://bugzilla.suse.com/show_bug.cgi?id=1190261#c3 --- Comment #3 from Michal Suchanek <msuchanek@suse.com> --- There is no way to detect shim is used just like there is no way to detect secure boot is being used. Just like secure boot is enabled always and option to opt out is offered call mokutil always and offer configuration option to opt out. While it is possible to detect if secure boot is enabled for specific boot and it's probably possible to detect if specific boot went through shim as well it is common to disable system features for testing and troubleshooting, and if that changed how kernel and modules are installed it would make the boot state even more complex and harder to understand than it already is. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190261 https://bugzilla.suse.com/show_bug.cgi?id=1190261#c4 --- Comment #4 from Michal Suchanek <msuchanek@suse.com> --- This is how secure boot use is detected /etc/sysconfig/bootloader:SECURE_BOOT="yes" -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190261 https://bugzilla.suse.com/show_bug.cgi?id=1190261#c5 --- Comment #5 from Martin Wilck <martin.wilck@suse.com> --- I was thinking about `mokutil --sb-state`, as you can see above. That checks an efivar. What's wrong with that? Of course users can change it before the next boot, but that's outside our influence anyway. I would like to understand if there's a downside in not attempting to run mokutil when sb-state is "disabled". -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190261 https://bugzilla.suse.com/show_bug.cgi?id=1190261#c6 --- Comment #6 from Michal Suchanek <msuchanek@suse.com> --- How do you enable secure boot? - enable secure boot in that config and reinstall some packages (or use yast) - reboot and enable secure boot in BIOS -> now you have secure boot but if kernel scripts checked --sb-state you would not be able to boot/load modules How do you test that your problem is caused by lockdown in secure boot? - reboot and disable secure boot in BIOS - test stuff (1) - reboot again to enable secure boot - test stuff If at (1) something checked --sb-state to determine if certificates should be enrolled you are missing certificates and have more problems than just lockdown now. -> current state is irrelevant. The intention to (not) use secure boot is expressed in that config setting, and that's the only place to look. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190261 https://bugzilla.suse.com/show_bug.cgi?id=1190261#c7 --- Comment #7 from Martin Wilck <martin.wilck@suse.com> ---
-> current state is irrelevant. The intention to (not) use secure boot is expressed in that config setting, and that's the only place to look.
I have no clue about /etc/sysconfig/bootloader. Why is it relevant at all? The only setting that really matters is the BIOS setting. I have enabled or disabled SB a lot of times, without ever touching /etc/sysconfig/bootloader. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190261 https://bugzilla.suse.com/show_bug.cgi?id=1190261#c8 --- Comment #8 from Michal Suchanek <msuchanek@suse.com> --- Yes, it's by default enabled so long as platform can support SB so you do not need to touch it. If certificates need enrolling they are enrolled regardless of the BIOS setting so when you enable SB everything just works. Your proposal to look at the current BIOS state is a proposal to break this. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190261 https://bugzilla.suse.com/show_bug.cgi?id=1190261#c9 Joey Lee <jlee@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jlee@suse.com) | --- Comment #9 from Joey Lee <jlee@suse.com> --- Hi Martin, Actually, I still doesn't know the background after reading this bug. But... (In reply to Martin Wilck from comment #2)
Joey, is it possible to use mok-manager to import certificates in DB if secureboot is disabled?
No, mok-manager can only be used to enroll certificate to MOK varaible. UEFI DB is a authenticated variable. MokManager can not write it. Unless user enable setup mode and run a EFI tool to enroll key to db. But normally machine will not in setup mode. Why you want to use MokManager to enroll DB?
If it isn't, we could skip the mokutil step in that case.
Or would it make sense to enroll the certs anyway, just in case SB is enabled at a later time?
MokManager still works for enrolling MOK when secure boot is disabled. It's _NOT_ secure, but works. Enrolling kernel signkey is useful when the CA of the kernel signkey is different with the CA in shim. Shim can use MOK to verify kernel binary. On the other hand, there is a way to detect whether system boot from shim. Just check the existence of this file: /sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23 This file is created by shim when booting. If system doesn't boot from shim (e.g. direct boot from EFI stub), then this MokListRT variable will not exist. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190261 https://bugzilla.suse.com/show_bug.cgi?id=1190261#c10 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #10 from Martin Wilck <martin.wilck@suse.com> --- (In reply to Joey Lee from comment #9)
Why you want to use MokManager to enroll DB?
I meant MOK, sorry.
If it isn't, we could skip the mokutil step in that case.
Or would it make sense to enroll the certs anyway, just in case SB is enabled at a later time?
MokManager still works for enrolling MOK when secure boot is disabled. It's _NOT_ secure, but works. Enrolling kernel signkey is useful when the CA of the kernel signkey is different with the CA in shim. Shim can use MOK to verify kernel binary.
If that's the case, I think we should always try to enroll from the kernel rpm scriptlet. The use case is: 1. user has SB disabled 2. kernel with new key is installed 3. user enables SB some time later If we didn't enroll and install in 2.), booting might fail after 3.). Of course the user can still skip actually installing the key during boot, that that's outside our responsibility, and it could happen even if SB was enabled. (Did I ever mention that MokManager's UI is horrible?).
On the other hand, there is a way to detect whether system boot from shim. Just check the existence of this file: /sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23
This file is created by shim when booting. If system doesn't boot from shim (e.g. direct boot from EFI stub), then this MokListRT variable will not exist.
Thanks for the info, but in view of what you wrote before, I think we'd better try to enroll the key anyway. I am going to close this bug now. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com