The lockdown function be enabled in master branch of openSUSE kernel
Hi folks, After testing NVIDIA kmp with lockdown kernel, the lockdown function be enabled in master branch of openSUSE Tumbleweed kernel again. (SLE and Leap kernels are already enabled) The following patches are unmartked: patches.suse/0001-security-lockdown-expose-a-hook-to-lock-the-kernel-down.patch patches.suse/0002-efi-Add-an-EFI_SECURE_BOOT-flag-to-indicate-secure-boot-mode.patch patches.suse/0003-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mode.patch patches.suse/0004-efi-Lock-down-the-kernel-at-the-integrity-level-if-b.patch patches.suse/arm64-lock-down-kernel-in-secure-boot-mode.patch The following config be enabled. It will load MOK (machine owner key) to kernel keyring: CONFIG_IMA_ARCH_POLICY=y CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y The following downstream config be enabled on x86_64 and aarch64. It will connect lockdown function with secure boot option in EFI firmware: CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y Kernel will set to integrity lockdown mode when secure boot be enabled: linux/security.h enum lockdown_reason { LOCKDOWN_NONE, LOCKDOWN_MODULE_SIGNATURE, // kernel module verification LOCKDOWN_DEV_MEM, LOCKDOWN_EFI_TEST, LOCKDOWN_KEXEC, LOCKDOWN_HIBERNATION, LOCKDOWN_PCI_ACCESS, LOCKDOWN_IOPORT, LOCKDOWN_MSR, LOCKDOWN_ACPI_TABLES, LOCKDOWN_DEVICE_TREE, LOCKDOWN_PCMCIA_CIS, LOCKDOWN_TIOCSSERIAL, LOCKDOWN_MODULE_PARAMETERS, LOCKDOWN_MMIOTRACE, LOCKDOWN_DEBUGFS, // restricted debugfs LOCKDOWN_XMON_WR, LOCKDOWN_BPF_WRITE_USER, // BPF write LOCKDOWN_DBG_WRITE_KERNEL, LOCKDOWN_RTAS_ERROR_INJECTION, LOCKDOWN_INTEGRITY_MAX, // integrity mode LOCKDOWN_KCORE, LOCKDOWN_KPROBES, LOCKDOWN_BPF_READ_KERNEL, // BPF read LOCKDOWN_DBG_READ_KERNEL, LOCKDOWN_PERF, LOCKDOWN_TRACEFS, LOCKDOWN_XMON_RW, LOCKDOWN_XFRM_SECRET, LOCKDOWN_CONFIDENTIALITY_MAX, // confidentiality mode }; As you see, the kernel module verification will be enabled. So please sign your self-built kernel module. You can reference this section in openSUSE UEFI wiki page: https://en.opensuse.org/openSUSE:UEFI#Signing_kernel_module_for_verification Please enroll your key to MOK by mokutil. If you didn't use shim, e.g. systemd-boot/dracut solution. I have created a bug bsc#1211224. Currently we do not support it with secure boot. Let's discuss it in bsc#1211224. Regards Joey Lee
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.
On 08. 06. 23, 7:13, 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? IMO yes, the same as the kernel.
-- js suse labs
On 08. 06. 23, 8:59, Jiri Slaby wrote:
On 08. 06. 23, 7:13, 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? IMO yes, the same as the kernel.
Like this:
is_efi () { local msg rc=0
# The below statement fails if mokutil isn't installed or UEFI is unsupported. # It doesn't fail if UEFI is available but secure boot is off. msg="$(mokutil --sb-state 2>&1)" || rc=$?
[ -z "$KERNEL_PACKAGE_SCRIPT_DEBUG" ] || echo "$msg" return $rc}
if ! is_efi; then [ -z "$KERNEL_PACKAGE_SCRIPT_DEBUG" ] || \ echo "$0: system doesn't support UEFI, skipping certificate handling" >&2 exit 0 fi
-- js suse labs
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? Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH Tel: 0911-740 53 0 Frankenstraße 146 FAX: 0911-740 53 479 D-90461 Nürnberg http://www.suse.de Germany ---------------------------------------------------------------- Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg) ----------------------------------------------------------------
On 10. 06. 23, 11:13, 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?
It's also about turning SB once. You install everything incl. nvidia. You reboot, enable SB. And bang, you have a problem -- nvidia won't load.
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?
The key for the kernel is always the same, so enrolled once in MOK. (Once every time you install a kernel from a different project.) But nvidia is different, right? The key differs on every update. Or not? If so, @joey, can the mok question appear only when SB is actually enabled? If not, asking the users once (the same as kernel) is not a problem... thanks, -- js suse labs
On Mon, Jun 12, 2023 at 10:48:35AM +0200, Jiri Slaby wrote:
On 10. 06. 23, 11:13, 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?
It's also about turning SB once. You install everything incl. nvidia. You reboot, enable SB. And bang, you have a problem -- nvidia won't load.
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?
The key for the kernel is always the same, so enrolled once in MOK. (Once every time you install a kernel from a different project.)
But nvidia is different, right? The key differs on every update. Or not?
Exactly. With each nvidia driver *and* kernel update we generate a new key/certificate. Unfortunately we can't keep the SB key on the disk for security reasons.
If so, @joey, can the mok question appear only when SB is actually enabled?
Yes, this would make sense.
If not, asking the users once (the same as kernel) is not a problem...
? Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH Tel: 0911-740 53 0 Frankenstraße 146 FAX: 0911-740 53 479 D-90461 Nürnberg http://www.suse.de Germany ---------------------------------------------------------------- Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg) ----------------------------------------------------------------
On Mon, Jun 12, 2023 at 02:23:58PM +0300, Andrei Borzenkov wrote:
On 12.06.2023 11:48, Jiri Slaby wrote:
If so, @joey, can the mok question appear only when SB is actually enabled?
It will not help. Enrollment request is one-time only - shim will delete all pending requests whether they are acted upon or not.
Yes, current behavior of MokManager is that it shows up when it saw the EFI variable be generated by "mokutil --import" command, which means that the MokNew and MokAuth EFI variable bes generated. MokNew is the new mok and MokAuth is the sha256 hash of one time password for enrolling. The MokAuth will be removed if user didn't enroll it in next booting. I prefer that do NOT change this behavior because security reason. Keeping the enroll request until secure boot doesn't make sense. The mok enrollment request should only survive in one reboot cycle. For NVIDIA driver, we may need to tell user to manually enroll the one time public key to MOK before they choice to enable secure boot. (switch from disable state). I will add this notice message to openSUSE:EFI wiki page. Hi Stefan, Where is the place for keeping the public key of NVIDIA driver? I want to add a mokutil command to wiki page to tell user to run it before they switch secure boot from disable to enable. Thanks a lot! Joey Lee
On Tue, Jun 13, 2023 at 02:23:34PM +0800, joeyli wrote:
On Mon, Jun 12, 2023 at 02:23:58PM +0300, Andrei Borzenkov wrote:
On 12.06.2023 11:48, Jiri Slaby wrote:
If so, @joey, can the mok question appear only when SB is actually enabled?
It will not help. Enrollment request is one-time only - shim will delete all pending requests whether they are acted upon or not.
Yes, current behavior of MokManager is that it shows up when it saw the EFI variable be generated by "mokutil --import" command, which means that the MokNew and MokAuth EFI variable bes generated. MokNew is the new mok and MokAuth is the sha256 hash of one time password for enrolling.
The MokAuth will be removed if user didn't enroll it in next booting. I prefer ^^^^^^^ MokNew and MokAuth will be removed
Sorry for my typo. Joey Lee
On Tue, Jun 13, 2023 at 02:23:34PM +0800, joeyli wrote:
For NVIDIA driver, we may need to tell user to manually enroll the one time public key to MOK before they choice to enable secure boot. (switch from disable state). I will add this notice message to openSUSE:EFI wiki page.
Hi Stefan,
Where is the place for keeping the public key of NVIDIA driver? I want to add a mokutil command to wiki page to tell user to run it before they switch secure boot from disable to enable.
https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot --- In case you miss the timeout for certificate enrollment after first reboot, you can easily import again the certificate by running the following command: For nvidia-driver-G0X (X >= 6): # mokutil --import /var/lib/nvidia-pubkeys/MOK-nvidia-driver-G0<X>-<driver_version>-<kernel_flavor>.der --root-pw * For nvidia-gfxG0X (G < 6): # mokutil --import /var/lib/nvidia-pubkeys/MOK-nvidia-gfxG0<X>-<driver_version>-<kernel_flavor>.der --root-pw Then reboot the machine and enroll the certificate as described before. --- Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH Tel: 0911-740 53 0 Frankenstraße 146 FAX: 0911-740 53 479 D-90461 Nürnberg http://www.suse.de Germany ---------------------------------------------------------------- Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg) ----------------------------------------------------------------
On Tue, Jun 13, 2023 at 12:33 PM Stefan Dirsch <sndirsch@suse.de> wrote: ...
# mokutil --import /var/lib/nvidia-pubkeys/MOK-nvidia-driver-G0<X>-<driver_version>-<kernel_flavor>.der --root-pw
...
Then reboot the machine and enroll the certificate as described before.
Do not expect that users will magically know what password to use in MokManager. You may think that "--root-pw" is clear enough - it is not for average users (all this is really black magic to them).
On Tue, Jun 13, 2023 at 12:37:53PM +0300, Andrei Borzenkov wrote:
On Tue, Jun 13, 2023 at 12:33 PM Stefan Dirsch <sndirsch@suse.de> wrote: ...
# mokutil --import /var/lib/nvidia-pubkeys/MOK-nvidia-driver-G0<X>-<driver_version>-<kernel_flavor>.der --root-pw
...
Then reboot the machine and enroll the certificate as described before.
Do not expect that users will magically know what password to use in MokManager. You may think that "--root-pw" is clear enough - it is not for average users (all this is really black magic to them).
Good that you mention it. I described this before in https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot --- [...] Use your root password (US keyboard layout!) when prompted for a password. [...] --- but we should mention this in this extra document as well! Or we just refer to this link from the document. Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH Tel: 0911-740 53 0 Frankenstraße 146 FAX: 0911-740 53 479 D-90461 Nürnberg http://www.suse.de Germany ---------------------------------------------------------------- Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg) ----------------------------------------------------------------
On 2023-06-13 11:43, Stefan Dirsch wrote:
On Tue, Jun 13, 2023 at 12:37:53PM +0300, Andrei Borzenkov wrote:
On Tue, Jun 13, 2023 at 12:33 PM Stefan Dirsch <sndirsch@suse.de> wrote: ...
# mokutil --import /var/lib/nvidia-pubkeys/MOK-nvidia-driver-G0<X>-<driver_version>-<kernel_flavor>.der --root-pw
...
Then reboot the machine and enroll the certificate as described before.
Do not expect that users will magically know what password to use in MokManager. You may think that "--root-pw" is clear enough - it is not for average users (all this is really black magic to them).
Good that you mention it. I described this before in
https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot
[...] Use your root password (US keyboard layout!) when prompted for a password. [...]
but we should mention this in this extra document as well! Or we just refer to this link from the document.
Sorry for being late to the discussion, but as user I can tell you that when the prompt appears, users think it comes from the BIOS (EFI), not from the Linux install. So one thinks of the BIOS password, or that it is some BIOS silliness. What the heck is this screen? I'd suggest you add some help text to that screen, and the SUSE/openSUSE name prominently. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Wed, Jul 12, 2023 at 09:08:04AM +0200, Carlos E. R. wrote:
On 2023-06-13 11:43, Stefan Dirsch wrote:
On Tue, Jun 13, 2023 at 12:37:53PM +0300, Andrei Borzenkov wrote:
On Tue, Jun 13, 2023 at 12:33 PM Stefan Dirsch <sndirsch@suse.de> wrote: ...
# mokutil --import /var/lib/nvidia-pubkeys/MOK-nvidia-driver-G0<X>-<driver_version>-<kernel_flavor>.der --root-pw
...
Then reboot the machine and enroll the certificate as described before.
Do not expect that users will magically know what password to use in MokManager. You may think that "--root-pw" is clear enough - it is not for average users (all this is really black magic to them).
Good that you mention it. I described this before in
https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot
[...] Use your root password (US keyboard layout!) when prompted for a password. [...]
but we should mention this in this extra document as well! Or we just refer to this link from the document.
Sorry for being late to the discussion, but as user I can tell you that when the prompt appears, users think it comes from the BIOS (EFI), not from the Linux install. So one thinks of the BIOS password, or that it is some BIOS silliness. What the heck is this screen?
I'd suggest you add some help text to that screen, and the SUSE/openSUSE name prominently.
Thanks for the feedback. Could you open a bugzilla ticket, so this can properly be tracked? Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH Tel: 0911-740 53 0 Frankenstraße 146 FAX: 0911-740 53 479 D-90461 Nürnberg http://www.suse.de Germany ---------------------------------------------------------------- Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg) ----------------------------------------------------------------
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. Thanks Michal
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 :) 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... thanks, Takashi
On 6/13/23 14:46, 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 :)
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...
AFAIK the GUI is yast2-bootloader, checkbox "Secure Boot support".
thanks,
Takashi
On Tue, 13 Jun 2023 14:50:36 +0200, Vlastimil Babka wrote:
On 6/13/23 14:46, 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 :)
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...
AFAIK the GUI is yast2-bootloader, checkbox "Secure Boot support".
Oh, thanks. Then this made me wonder how we can do handle better: I don't think this checkbox will do the automatic MOK deployment when nvidia driver was installed beforehand. So, have a check of /etc/sysconfig/bootloader:SECURE_BOOT instead of --sb-state option would give you a similar dilemma. When switching it, it won't work automagically but some manual work is still needed. Takashi
On Tue, Jun 13, 2023 at 03:02:24PM +0200, Takashi Iwai wrote:
On Tue, 13 Jun 2023 14:50:36 +0200, Vlastimil Babka wrote:
On 6/13/23 14:46, 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 :)
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...
AFAIK the GUI is yast2-bootloader, checkbox "Secure Boot support".
Oh, thanks.
Then this made me wonder how we can do handle better: I don't think this checkbox will do the automatic MOK deployment when nvidia driver was installed beforehand. So, have a check of /etc/sysconfig/bootloader:SECURE_BOOT instead of --sb-state option would give you a similar dilemma. When switching it, it won't work automagically but some manual work is still needed.
The default is to enable secure boot when it is supported. If you disable it then you do not get keys enrolled, and it's difficult to fix. Something that could be improved but is somwhat unrelated to the probblem at hand. It's been like this on Leap for years. Thanks Michal
On Wed, 14 Jun 2023 13:07:41 +0200, Michal Suchánek wrote:
On Tue, Jun 13, 2023 at 03:02:24PM +0200, Takashi Iwai wrote:
On Tue, 13 Jun 2023 14:50:36 +0200, Vlastimil Babka wrote:
On 6/13/23 14:46, 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 :)
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...
AFAIK the GUI is yast2-bootloader, checkbox "Secure Boot support".
Oh, thanks.
Then this made me wonder how we can do handle better: I don't think this checkbox will do the automatic MOK deployment when nvidia driver was installed beforehand. So, have a check of /etc/sysconfig/bootloader:SECURE_BOOT instead of --sb-state option would give you a similar dilemma. When switching it, it won't work automagically but some manual work is still needed.
The default is to enable secure boot when it is supported. If you disable it then you do not get keys enrolled, and it's difficult to fix.
Something that could be improved but is somwhat unrelated to the probblem at hand. It's been like this on Leap for years.
True, and it implies that this switch isn't much used, too ;) Takashi
On Wed, Jun 14, 2023 at 01:13:19PM +0200, Takashi Iwai wrote:
On Wed, 14 Jun 2023 13:07:41 +0200, Michal Suchánek wrote:
On Tue, Jun 13, 2023 at 03:02:24PM +0200, Takashi Iwai wrote:
On Tue, 13 Jun 2023 14:50:36 +0200, Vlastimil Babka wrote:
On 6/13/23 14:46, 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 :)
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...
AFAIK the GUI is yast2-bootloader, checkbox "Secure Boot support".
Oh, thanks.
Then this made me wonder how we can do handle better: I don't think this checkbox will do the automatic MOK deployment when nvidia driver was installed beforehand. So, have a check of /etc/sysconfig/bootloader:SECURE_BOOT instead of --sb-state option would give you a similar dilemma. When switching it, it won't work automagically but some manual work is still needed.
The default is to enable secure boot when it is supported. If you disable it then you do not get keys enrolled, and it's difficult to fix.
Something that could be improved but is somwhat unrelated to the probblem at hand. It's been like this on Leap for years.
True, and it implies that this switch isn't much used, too ;)
I have discussed the bootloader:SECURE_BOOT flag with Gary Lin yesterday. If user choice NO (did not select it when installation), then shim and signed-grub2 will not be installed. A unsigned(?) grub2 will be used. Regards Joey Lee
On Thu, 15 Jun 2023 09:15:38 +0200, joeyli wrote:
On Wed, Jun 14, 2023 at 01:13:19PM +0200, Takashi Iwai wrote:
On Wed, 14 Jun 2023 13:07:41 +0200, Michal Suchánek wrote:
On Tue, Jun 13, 2023 at 03:02:24PM +0200, Takashi Iwai wrote:
On Tue, 13 Jun 2023 14:50:36 +0200, Vlastimil Babka wrote:
On 6/13/23 14:46, 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 :)
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...
AFAIK the GUI is yast2-bootloader, checkbox "Secure Boot support".
Oh, thanks.
Then this made me wonder how we can do handle better: I don't think this checkbox will do the automatic MOK deployment when nvidia driver was installed beforehand. So, have a check of /etc/sysconfig/bootloader:SECURE_BOOT instead of --sb-state option would give you a similar dilemma. When switching it, it won't work automagically but some manual work is still needed.
The default is to enable secure boot when it is supported. If you disable it then you do not get keys enrolled, and it's difficult to fix.
Something that could be improved but is somwhat unrelated to the probblem at hand. It's been like this on Leap for years.
True, and it implies that this switch isn't much used, too ;)
I have discussed the bootloader:SECURE_BOOT flag with Gary Lin yesterday. If user choice NO (did not select it when installation), then shim and signed-grub2 will not be installed. A unsigned(?) grub2 will be used.
It sounds good, but also it means that, when this checkbox is toggled on the running system, shim and signed-grub2 have to be installed automatically? I believe YaST currently just toggles the config variable, but we'll need more than that. thanks, Takashi
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.
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. Thanks Michal
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
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
On Tue, 13 Jun 2023 16:05:37 +0200, Michal Suchánek wrote:
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:
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.
Yes, the argument is only about the special use case of Nvidia; unfortunately it has large user base and a sort of "must" item.
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.
Right, and that's the sole reason Nvidia driver package uses a one-time key. So we go back to square... :-< Takashi
On Tue, Jun 13, 2023 at 04:19:32PM +0200, Takashi Iwai wrote:
On Tue, 13 Jun 2023 16:05:37 +0200, Michal Suchánek wrote:
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:
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.
Yes, the argument is only about the special use case of Nvidia; unfortunately it has large user base and a sort of "must" item.
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.
Right, and that's the sole reason Nvidia driver package uses a one-time key. So we go back to square... :-<
And why does it have to be one time key? That's what upstream recomends but it also recommends to make lockdown independet of secure boot, and next to nobody uses that. From the https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS DKMS documentation it looks like it uses a permanent key. Of course, storing permanent key on disk is somewhat less secure than ephemeral key but besides usability there is also the concern of wearing down the flash storage holding firmware configuration by enrolling new key on every update. Thanks Michal
On Wed, 14 Jun 2023 13:04:55 +0200, Michal Suchánek wrote:
On Tue, Jun 13, 2023 at 04:19:32PM +0200, Takashi Iwai wrote:
On Tue, 13 Jun 2023 16:05:37 +0200, Michal Suchánek wrote:
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:
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.
Yes, the argument is only about the special use case of Nvidia; unfortunately it has large user base and a sort of "must" item.
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.
Right, and that's the sole reason Nvidia driver package uses a one-time key. So we go back to square... :-<
And why does it have to be one time key? That's what upstream recomends but it also recommends to make lockdown independet of secure boot, and next to nobody uses that.
From the https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS DKMS documentation it looks like it uses a permanent key.
Of course, storing permanent key on disk is somewhat less secure than ephemeral key but besides usability there is also the concern of wearing down the flash storage holding firmware configuration by enrolling new key on every update.
Yes, it's somewhat I had in mind: allow user to specify some fixed path for a key in a config like /etc/sysconfig/bootloader. If it's empty (as default), one-time key is used as the safest option. If it's stored in somewhere on a disk, it's user's responsibility for keeping it in a safe place. Takashi
On 13. 06. 23, 15:18, Takashi Iwai wrote:
Can we have a common scriptlet that can be triggered by YaST (or whatever) tool for managing that?
I think we need one. Something like {/usr,}/etc/sb-state-changed.d/. Or it can simply be a shutdown (user enabled SB in the config) _and_ startup (BIOS enabled SB) script. The startup one would trigger a reboot after rebuilding and installing the key. The obvious question: what do other distros do? thanks, -- js suse labs
On Wed, Jun 14, 2023 at 06:52:03AM +0200, Jiri Slaby wrote:
On 13. 06. 23, 15:18, Takashi Iwai wrote:
Can we have a common scriptlet that can be triggered by YaST (or whatever) tool for managing that?
I think we need one. Something like {/usr,}/etc/sb-state-changed.d/. Or it can simply be a shutdown (user enabled SB in the config) _and_ startup (BIOS enabled SB) script. The startup one would trigger a reboot after rebuilding and installing the key.
The obvious question: what do other distros do?
I was checked shim signature and kernel embedded keys in Fedora 37, CentOS 9 and Ubuntu 22.10. I have put the result on bsc#1198101. The point is: I didn't found KMP from Fedora of Ubuntu online update. Maybe I missed. Or maybe that they do not provide online update of KMP, especially NVIDIA driver, so they do not worry about the local-built with one time signkey problem. The following is checking result for reference. Somethings can be confirmed: - All of their kernel are locked-down on integrity mode when BIOS secure boot option is enabled. - All of them used different signkey to sign kernel and in-tree kernel module. Especially Ubuntu uses 'Build time autogenerated kernel key' to sign kernel module. And, the key be embedded to kernel when building. - I didn't found KMPs of them, so I can not check the signature of the .ko file for out-of-tree kernel module. Results for reference (also on bsc#1198101): Fedora 37: - shim: Microsoft signature (only Microsoft signed) embedded key: 'Fedora Secure Boot CA' - kernel: Two signatures: 'Fedora Secure Boot Signer' <-- Fedora Secure Boot CA signature for shim verify 'kernel-signer' signed <-- Fedora kernel signing key signature, for kexec? embedded key: 'Fedora kernel signing key' - In-tree Kernel Module: 'Fedora kernel signing key' signature - *.ko in KMP: I didn't find Fedora KMP yet, only saw user guide for how to self-sign kernel module. So, the key embedded in Fedora shim can only be used to load kernel but not verify kernel module. CentOS 9: - shim: Signature: Microsoft Windows UEFI Driver Publisher signature Embedded key: 'CentOS Secure Boot CA 2' - kernel: Signature: CentOS Secure Boot Signing 201 (Issuer: CentOS Secure Boot CA 2) Embedded key: 'CentOS Stream kernel signing key' 'Red Hat Enterprise Linux Driver Update Program (key 3)' 'Red Hat Enterprise Linux kpatch signing key' - In-tree Kernel Module: Signature: 'CentOS Stream kernel signing key' - *.ko in KMP: I didn't find CentOS KMP yet. CentOS 9 also uses different key to sign kernel and in-tree kernel modules. On the other hand, CentOS and Fedora are lock-down when secure boot be enabled: [root@Vigor111 boot]# cat /sys/kernel/security/lockdown none [integrity] confidentiality Ubuntu 22.10: Ubuntu is interesting, they use a "Build time autogenerated kernel key" to sign in-tree modules. I believe it's a one time key. - shim: Signature: Microsoft Windows UEFI Driver Publisher signature Embedded key: 'Canonical Ltd. Master Certificate Authority' <-- Ubuntu CA - kernel: Signature: Canonical Ltd. Secure Boot Signing (2017) (Issuer: Canonical Ltd. Master Certificate Authority) Embedded key: 'Build time autogenerated kernel key' 'Canonical Ltd. Live Patch Signing' 'Canonical Ltd. Kernel Module Signing' - In-tree Kernel Module: Signature: 'Build time autogenerated kernel key' - *.ko in KMP: I didn't find Ubuntu KMP yet. Ubuntu 22.10 also uses different key to sign kernel and in-tree kernel modules. And the key for signing in-tree kernel modules is a one time key. Like CentOS and Fedora, Ubuntu kernel lock-down when secure boot be enabled: root@ubuntu2210:/home/linux# cat /sys/kernel/security/lockdown none [integrity] confidentiality Thanks Joey Lee
On Wed, Jun 14, 2023 at 05:40:38PM +0800, joeyli wrote:
The obvious question: what do other distros do?
I was checked shim signature and kernel embedded keys in Fedora 37, CentOS 9 and Ubuntu 22.10. I have put the result on bsc#1198101.
The point is: I didn't found KMP from Fedora of Ubuntu online update. Maybe I missed. Or maybe that they do not provide online update of KMP, especially NVIDIA driver, so they do not worry about the local-built with one time signkey problem.
RH/CentOS use DKMS for building the driver. Ubuntu probably also uses DKMS or something comparable, so they also build it on-the-fly and I assume they need to sign the modules as well for SB. CU, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH Tel: 0911-740 53 0 Frankenstraße 146 FAX: 0911-740 53 479 D-90461 Nürnberg http://www.suse.de Germany ---------------------------------------------------------------- Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg) ----------------------------------------------------------------
On Wed, Jun 14, 2023 at 12:53:07PM +0200, Stefan Dirsch wrote:
On Wed, Jun 14, 2023 at 05:40:38PM +0800, joeyli wrote:
The obvious question: what do other distros do?
I was checked shim signature and kernel embedded keys in Fedora 37, CentOS 9 and Ubuntu 22.10. I have put the result on bsc#1198101.
The point is: I didn't found KMP from Fedora of Ubuntu online update. Maybe I missed. Or maybe that they do not provide online update of KMP, especially NVIDIA driver, so they do not worry about the local-built with one time signkey problem.
RH/CentOS use DKMS for building the driver. Ubuntu probably also uses DKMS or something comparable, so they also build it on-the-fly and I assume they need to sign the modules as well for SB.
With a fixed key that is generated and enrolled the first time DKMS isused, AFAICT. Thanks Michal
On 08. 06. 23, 6:54, joeyli wrote:
Hi folks,
After testing NVIDIA kmp with lockdown kernel, the lockdown function be enabled in master branch of openSUSE Tumbleweed kernel again. (SLE and Leap kernels are already enabled)
Hi, thanks Joey for the write-up. I amend that this means the 6.4 kernel will have all this once merged to Tumbleweed. That means you have 3-5 weeks to set up and test all of this against the master branch. You can find the kernel in obs://Kernel:HEAD, so you can obtain it from: https://download.opensuse.org/repositories/Kernel:/HEAD/standard/ thanks, -- js suse labs
Hi, Kernel 6.4 is submitted to factory as SR#1095360. It will take some time for us to fix all 6.4's fallouts. But once it is merged, lockdown will enabled in Tumbleweed again. For all the details, see Joey's e-mail below. (You can test the kernel in Kernel:stable, if you are not sure everything is going to work for you.) On 08. 06. 23, 6:54, joeyli via openSUSE Factory wrote:
Hi folks,
After testing NVIDIA kmp with lockdown kernel, the lockdown function be enabled in master branch of openSUSE Tumbleweed kernel again. (SLE and Leap kernels are already enabled)
The following patches are unmartked:
patches.suse/0001-security-lockdown-expose-a-hook-to-lock-the-kernel-down.patch patches.suse/0002-efi-Add-an-EFI_SECURE_BOOT-flag-to-indicate-secure-boot-mode.patch patches.suse/0003-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mode.patch patches.suse/0004-efi-Lock-down-the-kernel-at-the-integrity-level-if-b.patch patches.suse/arm64-lock-down-kernel-in-secure-boot-mode.patch
The following config be enabled. It will load MOK (machine owner key) to kernel keyring:
CONFIG_IMA_ARCH_POLICY=y CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y
The following downstream config be enabled on x86_64 and aarch64. It will connect lockdown function with secure boot option in EFI firmware:
CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y
Kernel will set to integrity lockdown mode when secure boot be enabled:
linux/security.h enum lockdown_reason { LOCKDOWN_NONE, LOCKDOWN_MODULE_SIGNATURE, // kernel module verification LOCKDOWN_DEV_MEM, LOCKDOWN_EFI_TEST, LOCKDOWN_KEXEC, LOCKDOWN_HIBERNATION, LOCKDOWN_PCI_ACCESS, LOCKDOWN_IOPORT, LOCKDOWN_MSR, LOCKDOWN_ACPI_TABLES, LOCKDOWN_DEVICE_TREE, LOCKDOWN_PCMCIA_CIS, LOCKDOWN_TIOCSSERIAL, LOCKDOWN_MODULE_PARAMETERS, LOCKDOWN_MMIOTRACE, LOCKDOWN_DEBUGFS, // restricted debugfs LOCKDOWN_XMON_WR, LOCKDOWN_BPF_WRITE_USER, // BPF write LOCKDOWN_DBG_WRITE_KERNEL, LOCKDOWN_RTAS_ERROR_INJECTION, LOCKDOWN_INTEGRITY_MAX, // integrity mode LOCKDOWN_KCORE, LOCKDOWN_KPROBES, LOCKDOWN_BPF_READ_KERNEL, // BPF read LOCKDOWN_DBG_READ_KERNEL, LOCKDOWN_PERF, LOCKDOWN_TRACEFS, LOCKDOWN_XMON_RW, LOCKDOWN_XFRM_SECRET, LOCKDOWN_CONFIDENTIALITY_MAX, // confidentiality mode };
As you see, the kernel module verification will be enabled. So please sign your self-built kernel module. You can reference this section in openSUSE UEFI wiki page:
https://en.opensuse.org/openSUSE:UEFI#Signing_kernel_module_for_verification
Please enroll your key to MOK by mokutil.
If you didn't use shim, e.g. systemd-boot/dracut solution. I have created a bug bsc#1211224. Currently we do not support it with secure boot. Let's discuss it in bsc#1211224.
Regards Joey Lee
regards, -- js suse labs
On Thu, Jun 29, 2023 at 09:59:36AM +0200, Jiri Slaby wrote:
Hi,
Kernel 6.4 is submitted to factory as SR#1095360. It will take some time for us to fix all 6.4's fallouts. But once it is merged, lockdown will enabled in Tumbleweed again.
For all the details, see Joey's e-mail below.
(You can test the kernel in Kernel:stable, if you are not sure everything is going to work for you.)
Just did a test with NVIDIA proprietary driver. Kernel update from Kernel:stable triggers rebuild of modules, signs them - as expected. And after boot you can accept the new certificate. Reboot again and nvidia modules are working with Kernel 6.4. Desktop works, glxinfo and vulkaninfo does. So looks good from my side. Thanks, Stefan
On 08. 06. 23, 6:54, joeyli via openSUSE Factory wrote:
Hi folks,
After testing NVIDIA kmp with lockdown kernel, the lockdown function be enabled in master branch of openSUSE Tumbleweed kernel again. (SLE and Leap kernels are already enabled)
The following patches are unmartked:
patches.suse/0001-security-lockdown-expose-a-hook-to-lock-the-kernel-down.patch patches.suse/0002-efi-Add-an-EFI_SECURE_BOOT-flag-to-indicate-secure-boot-mode.patch patches.suse/0003-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mode.patch patches.suse/0004-efi-Lock-down-the-kernel-at-the-integrity-level-if-b.patch patches.suse/arm64-lock-down-kernel-in-secure-boot-mode.patch
The following config be enabled. It will load MOK (machine owner key) to kernel keyring:
CONFIG_IMA_ARCH_POLICY=y CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y
The following downstream config be enabled on x86_64 and aarch64. It will connect lockdown function with secure boot option in EFI firmware:
CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y
Kernel will set to integrity lockdown mode when secure boot be enabled:
linux/security.h enum lockdown_reason { LOCKDOWN_NONE, LOCKDOWN_MODULE_SIGNATURE, // kernel module verification LOCKDOWN_DEV_MEM, LOCKDOWN_EFI_TEST, LOCKDOWN_KEXEC, LOCKDOWN_HIBERNATION, LOCKDOWN_PCI_ACCESS, LOCKDOWN_IOPORT, LOCKDOWN_MSR, LOCKDOWN_ACPI_TABLES, LOCKDOWN_DEVICE_TREE, LOCKDOWN_PCMCIA_CIS, LOCKDOWN_TIOCSSERIAL, LOCKDOWN_MODULE_PARAMETERS, LOCKDOWN_MMIOTRACE, LOCKDOWN_DEBUGFS, // restricted debugfs LOCKDOWN_XMON_WR, LOCKDOWN_BPF_WRITE_USER, // BPF write LOCKDOWN_DBG_WRITE_KERNEL, LOCKDOWN_RTAS_ERROR_INJECTION, LOCKDOWN_INTEGRITY_MAX, // integrity mode LOCKDOWN_KCORE, LOCKDOWN_KPROBES, LOCKDOWN_BPF_READ_KERNEL, // BPF read LOCKDOWN_DBG_READ_KERNEL, LOCKDOWN_PERF, LOCKDOWN_TRACEFS, LOCKDOWN_XMON_RW, LOCKDOWN_XFRM_SECRET, LOCKDOWN_CONFIDENTIALITY_MAX, // confidentiality mode };
As you see, the kernel module verification will be enabled. So please sign your self-built kernel module. You can reference this section in openSUSE UEFI wiki page:
https://en.opensuse.org/openSUSE:UEFI#Signing_kernel_module_for_verification
Please enroll your key to MOK by mokutil.
If you didn't use shim, e.g. systemd-boot/dracut solution. I have created a bug bsc#1211224. Currently we do not support it with secure boot. Let's discuss it in bsc#1211224.
Regards Joey Lee
regards,
js suse labs
-- Regards, Stefan Dirsch Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH Tel: 0911-740 53 0 Frankenstraße 146 FAX: 0911-740 53 479 D-90461 Nürnberg http://www.suse.de Germany ---------------------------------------------------------------- Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg) ----------------------------------------------------------------
On 6/29/23 02:59, Jiri Slaby wrote:
Kernel 6.4 is submitted to factory as SR#1095360. It will take some time for us to fix all 6.4's fallouts. But once it is merged, lockdown will enabled in Tumbleweed again.
For all the details, see Joey's e-mail below.
(You can test the kernel in Kernel:stable, if you are not sure everything is going to work for you.)
VirtualBox kmp builds were broken in 6.4, but that has been fixed (boo#1212761). Note that the IBT problem for Intel processors from Gen 11+ has not been fixed. That will require Oracle finding a solution. Until they do, users of such processors will need to use "ibt=off" in their boot command line, otherwise the VB kmp's will not run [1]. Larry [1] https://forums.opensuse.org/t/virtualbox-fails-to-start-on-newest-cpus-with-...
On 29. 06. 23, 9:59, Jiri Slaby wrote:
Hi,
Kernel 6.4 is submitted to factory as SR#1095360. It will take some time for us to fix all 6.4's fallouts. But once it is merged, lockdown will enabled in Tumbleweed again.
Not really as a bad merge happened -- the lockdown patches were not enabled. This happened only now and the ongoing submission (SR#1098277) has lockdown enabled.
For all the details, see Joey's e-mail below.
(You can test the kernel in Kernel:stable, if you are not sure everything is going to work for you.)
So now, it's the right time ;).
On 08. 06. 23, 6:54, joeyli via openSUSE Factory wrote:
Hi folks,
After testing NVIDIA kmp with lockdown kernel, the lockdown function be enabled in master branch of openSUSE Tumbleweed kernel again. (SLE and Leap kernels are already enabled)
The following patches are unmartked:
patches.suse/0001-security-lockdown-expose-a-hook-to-lock-the-kernel-down.patch patches.suse/0002-efi-Add-an-EFI_SECURE_BOOT-flag-to-indicate-secure-boot-mode.patch patches.suse/0003-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mode.patch patches.suse/0004-efi-Lock-down-the-kernel-at-the-integrity-level-if-b.patch patches.suse/arm64-lock-down-kernel-in-secure-boot-mode.patch
The following config be enabled. It will load MOK (machine owner key) to kernel keyring:
CONFIG_IMA_ARCH_POLICY=y CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y
The following downstream config be enabled on x86_64 and aarch64. It will connect lockdown function with secure boot option in EFI firmware:
CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y
Kernel will set to integrity lockdown mode when secure boot be enabled:
linux/security.h enum lockdown_reason { LOCKDOWN_NONE, LOCKDOWN_MODULE_SIGNATURE, // kernel module verification LOCKDOWN_DEV_MEM, LOCKDOWN_EFI_TEST, LOCKDOWN_KEXEC, LOCKDOWN_HIBERNATION, LOCKDOWN_PCI_ACCESS, LOCKDOWN_IOPORT, LOCKDOWN_MSR, LOCKDOWN_ACPI_TABLES, LOCKDOWN_DEVICE_TREE, LOCKDOWN_PCMCIA_CIS, LOCKDOWN_TIOCSSERIAL, LOCKDOWN_MODULE_PARAMETERS, LOCKDOWN_MMIOTRACE, LOCKDOWN_DEBUGFS, // restricted debugfs LOCKDOWN_XMON_WR, LOCKDOWN_BPF_WRITE_USER, // BPF write LOCKDOWN_DBG_WRITE_KERNEL, LOCKDOWN_RTAS_ERROR_INJECTION, LOCKDOWN_INTEGRITY_MAX, // integrity mode LOCKDOWN_KCORE, LOCKDOWN_KPROBES, LOCKDOWN_BPF_READ_KERNEL, // BPF read LOCKDOWN_DBG_READ_KERNEL, LOCKDOWN_PERF, LOCKDOWN_TRACEFS, LOCKDOWN_XMON_RW, LOCKDOWN_XFRM_SECRET, LOCKDOWN_CONFIDENTIALITY_MAX, // confidentiality mode };
As you see, the kernel module verification will be enabled. So please sign your self-built kernel module. You can reference this section in openSUSE UEFI wiki page:
https://en.opensuse.org/openSUSE:UEFI#Signing_kernel_module_for_verification
Please enroll your key to MOK by mokutil.
If you didn't use shim, e.g. systemd-boot/dracut solution. I have created a bug bsc#1211224. Currently we do not support it with secure boot. Let's discuss it in bsc#1211224.
Regards Joey Lee
regards,
-- js suse labs
participants (9)
-
Andrei Borzenkov -
Carlos E. R. -
Jiri Slaby -
joeyli -
Larry Finger -
Michal Suchánek -
Stefan Dirsch -
Takashi Iwai -
Vlastimil Babka