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 6/12/23 05:12, Stefan Dirsch wrote:
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.
I don't use nvidia, but doesn't that mean that the MOK is going to end up with lots of keys for older nvidia drivers which are no longer even installed ? Could a user run into some limit on the number of keys installed ? Considering the number of updates and number of new kernels we see in TW, it would seem like a mess that will need to cleaned up at some point. Why does it always need a new key, couldn't you just generate once and reuse whenever the nvidia driver is updated ? That's what I have been doing with signing the vmware modules. Couldn't you use the same suse key that signs other stuff since the drivers are being provided by the distro ? -- Regards, Joe
On Tue, Jun 13, 2023 at 04:41:03PM -0400, Joe Salmeri wrote:
On 6/12/23 05:12, Stefan Dirsch wrote:
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.
I don't use nvidia, but doesn't that mean that the MOK is going to end up with lots of keys for older nvidia drivers which are no longer even installed ?
The keys are uninstalled from MOK when uninstalling the older driver. Well, of course you can ignore Mokmanager after reboot ...
Could a user run into some limit on the number of keys installed ?
I can't say. I'm not an expert here.
Considering the number of updates and number of new kernels we see in TW, it would seem like a mess that will need to cleaned up at some point.
Any suggestions to improve it?
Why does it always need a new key, couldn't you just generate once and reuse whenever the nvidia driver is updated ?
That's what I have been doing with signing the vmware modules.
On your system you can do this. Your risk. SUSE can't do this, i.e. keeping the generated private key on the harddisk.
Couldn't you use the same suse key that signs other stuff since the drivers are being provided by the distro ?
We're building and signing the driver on the target system. Of course we'll never ship our key for signing the kernel modules. 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 Wed, Jun 14, 2023 at 08:39:33AM -0000, Bruno Pitrus wrote:
On your system you can do this. Your risk. SUSE can't do this, i.e. keeping the generated private key on the harddisk.
If i sign the compiled modules with the same key that is in the secureboot db (NOT the MOK), will the kernel trust them?
What do you mean with 'secureboot db'? 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) ----------------------------------------------------------------
Hi Bruno, On Wed, Jun 14, 2023 at 08:39:33AM -0000, Bruno Pitrus wrote:
On your system you can do this. Your risk. SUSE can't do this, i.e. keeping the generated private key on the harddisk.
If i sign the compiled modules with the same key that is in the secureboot db (NOT the MOK), will the kernel trust them?
Upstream kernel only allows keys in db to be used to verify kexec images. We put downstream kernel patch to Tumbleweed kernel to allow db keys can be used to verify kernel module. But this expansion is only in kernel/module subsystem not in IMA. In the future, if the IMA-mok function for modsign is ready. We may remove this downstream patch because IMA is the official mechanism for handing integrity. Regards Joey Lee
On 6/13/23 19:09, Stefan Dirsch wrote:
The keys are uninstalled from MOK when uninstalling the older driver. Well, of course you can ignore Mokmanager after reboot ...
Considering the number of updates and number of new kernels we see in TW, it would seem like a mess that will need to cleaned up at some point. Any suggestions to improve it?
Since the keys are removed when the older driver is installed that should address the situation I raised.
Why does it always need a new key, couldn't you just generate once and reuse whenever the nvidia driver is updated ?
That's what I have been doing with signing the vmware modules. On your system you can do this. Your risk. SUSE can't do this, i.e. keeping the generated private key on the harddisk.
I see your point, however, when you setup Apache to use SSL for a website, you have to have both the public and private keys on disk. I guess the difference is the fact that in this case if the Nvidia private key was also on disk, then a bad actor could use it and the public key which is also on disk to sign a malicious code module. Is that what you meant by "my risk" or are there other reasons I had not considered? -- Regards, Joe
On Wed, Jun 14, 2023 at 09:31:24AM -0400, Joe Salmeri wrote:
On 6/13/23 19:09, Stefan Dirsch wrote:
The keys are uninstalled from MOK when uninstalling the older driver. Well, of course you can ignore Mokmanager after reboot ...
Considering the number of updates and number of new kernels we see in TW, it would seem like a mess that will need to cleaned up at some point. Any suggestions to improve it?
Since the keys are removed when the older driver is installed that should address the situation I raised.
Why does it always need a new key, couldn't you just generate once and reuse whenever the nvidia driver is updated ?
That's what I have been doing with signing the vmware modules. On your system you can do this. Your risk. SUSE can't do this, i.e. keeping the generated private key on the harddisk.
I see your point, however, when you setup Apache to use SSL for a website, you have to have both the public and private keys on disk.
I guess the difference is the fact that in this case if the Nvidia private key was also on disk, then a bad actor could use it and the public key which is also on disk to sign a malicious code module.
Is that what you meant by "my risk" or are there other reasons I had not considered?
Yes, that's basically it, and that's what other distributions seem to be doing with DKMS. Thanks Michal
Hi Joe, On Tue, Jun 13, 2023 at 04:41:03PM -0400, Joe Salmeri wrote:
On 6/12/23 05:12, Stefan Dirsch wrote:
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.
I don't use nvidia, but doesn't that mean that the MOK is going to end up with lots of keys for older nvidia drivers which are no longer even installed ?
Per my understood, old one time key will be removed.
Could a user run into some limit on the number of keys installed ?
It depends on the NVRAM size of firmware. Different firmware reserved different space for EFI variables. Should check with firmware team. Thanks Joey Lee
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) ----------------------------------------------------------------
Am 13.06.23 um 11:33 schrieb Stefan Dirsch:
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.
The only problem is that the key is only generated if secure boot is enabled. Without secure boot there is no key. So I propose to always create the key, but only try to enroll it, if secure boot is enabled. This will makes the secure boot decision at installation time not a once and forever decision. kind regards, Christian P.S. zypper in -f nvidia-driver-G06-kmp-default will create the key, but you will have to run it via the console and without help of the SDB document -- Christian Goll SUSE Software Solutions Germany GmbH +49 7133 2290220 CGoll@suse.com Frankenstraße 146 90461 Nürnberg Germany Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg) www.suse.com
On 13.06.23 11:33, Stefan Dirsch wrote:
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 /var/lib/nvidia-pubkeys does not exists on my Tumbleweed computer:
ls /var/lib/nvidia-pubkeys ls: cannot access '/var/lib/nvidia-pubkeys': No such file or directory rpm -qa | grep nvidia nvidia-video-G06-525.116.04-8.1.x86_64 nvidia-utils-G06-525.116.04-8.1.x86_64 nvidia-driver-G06-kmp-default-525.116.04_k6.3.1_1-8.1.x86_64 nvidia-compute-G06-32bit-525.116.04-8.1.x86_64 nvidia-compute-utils-G06-525.116.04-8.1.x86_64 kernel-firmware-nvidia-20230531-1.1.noarch nvidia-video-G06-32bit-525.116.04-8.1.x86_64 nvidia-compute-G06-525.116.04-8.1.x86_64 nvidia-gl-G06-32bit-525.116.04-8.1.x86_64 libnvidia-egl-wayland1-1.1.11-1.2.x86_64 nvidia-gl-G06-525.116.04-8.1.x86_64
Björn
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 6/14/23 07:04, Michal Suchánek wrote:
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
For non-rolling distros, that wouldn't be a concern, but for rolling distros, that would be a lot of updates. I'd like to believe that it would not cause the flash to fail sooner, but I imagine having to replace your motherboard because the flash failed. I guess one could turn off secure boot if that happened, however, wouldn't that be a write to the same flash that failed ? -- Regards, Joe
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
On Mon, Jun 12, 2023 at 06:26:06PM -0000, Bruno Pitrus wrote:
master branch of openSUSE Tumbleweed kernel Is it enabled in upstream? What problem would be it for you to ship an UNSIGNED kernel that has all the SUSE patches EXCEPT lockdown? You already ship kernel-vanilla, and AFAIK it does not have lockdown.
Mainline kernel has lockdown function but it didn't connect with the secure boot switch in firmware. Like other big distros (Fedora, Ubuntu, Leap/SLE), We put downstream patch to Tumbleweed kernel to connect lockdown-integrity mode with secure boot. About kernel-vanilla, a bsc#1209008 be created (I am not sure that it's public bug). We will ship unsigned kernel-vanilla without lockdown. Currently we do not have a SUSE-patched unsigned Tumbleweed kernel. We need a new kernel flavor against this. I don't know who has power to do the decision. Thanks Joey Lee
Hi Lubos, Sorry for bother you! On Wed, Jun 14, 2023 at 11:01:57PM +0800, joeyli via openSUSE Factory wrote:
On Mon, Jun 12, 2023 at 06:26:06PM -0000, Bruno Pitrus wrote:
master branch of openSUSE Tumbleweed kernel Is it enabled in upstream? What problem would be it for you to ship an UNSIGNED kernel that has all the SUSE patches EXCEPT lockdown? You already ship kernel-vanilla, and AFAIK it does not have lockdown.
Mainline kernel has lockdown function but it didn't connect with the secure boot switch in firmware. Like other big distros (Fedora, Ubuntu, Leap/SLE), We put downstream patch to Tumbleweed kernel to connect lockdown-integrity mode with secure boot.
About kernel-vanilla, a bsc#1209008 be created (I am not sure that it's public bug). We will ship unsigned kernel-vanilla without lockdown.
Currently we do not have a SUSE-patched unsigned Tumbleweed kernel. We need a new kernel flavor against this. I don't know who has power to do the decision.
In the systemd-boot with unified kernel image (UKI) case, community has voice that he wants to have a unsigned kernel with SUSE patches, and the kernel will not be locked-down. Because they want to produce UKI image and sign it by their personal key. SUSE will not be responsible for the integrity or verifiction of their self-signed UKI image. User should enroll their key to db by UEFI firmware UI manually. Could you please consider to create a openSUSE Tumbleweed Jira against this requirement? I think that we need a new kernel flavor for Tumbleweed to fill this requirement. Thanks a lot! Joey Lee
Hello, On Sat, Jun 17, 2023 at 10:49:09AM +0800, joeyli via openSUSE Factory wrote:
Hi Lubos,
Sorry for bother you!
On Wed, Jun 14, 2023 at 11:01:57PM +0800, joeyli via openSUSE Factory wrote:
On Mon, Jun 12, 2023 at 06:26:06PM -0000, Bruno Pitrus wrote:
master branch of openSUSE Tumbleweed kernel Is it enabled in upstream? What problem would be it for you to ship an UNSIGNED kernel that has all the SUSE patches EXCEPT lockdown? You already ship kernel-vanilla, and AFAIK it does not have lockdown.
Mainline kernel has lockdown function but it didn't connect with the secure boot switch in firmware. Like other big distros (Fedora, Ubuntu, Leap/SLE), We put downstream patch to Tumbleweed kernel to connect lockdown-integrity mode with secure boot.
About kernel-vanilla, a bsc#1209008 be created (I am not sure that it's public bug). We will ship unsigned kernel-vanilla without lockdown.
Currently we do not have a SUSE-patched unsigned Tumbleweed kernel. We need a new kernel flavor against this. I don't know who has power to do the decision.
In the systemd-boot with unified kernel image (UKI) case, community has voice that he wants to have a unsigned kernel with SUSE patches, and the kernel will not be locked-down. Because they want to produce UKI image and sign it by their personal key. SUSE will not be responsible for the integrity or verifiction of their self-signed UKI image. User should enroll their key to db by UEFI firmware UI manually.
Could you please consider to create a openSUSE Tumbleweed Jira against this requirement? I think that we need a new kernel flavor for Tumbleweed to fill this requirement.
This should be possible to do with config.addon mechanism - that is create a link of kernel-source and add an extra config file that disables the lockdown. As this is an unnofficial kernel anyone can create a link in a project of their choice. Thanks Michal
Hi Michal, On Thu, Jun 29, 2023 at 01:49:18PM +0200, Michal Suchánek wrote:
Hello,
On Sat, Jun 17, 2023 at 10:49:09AM +0800, joeyli via openSUSE Factory wrote:
Hi Lubos,
Sorry for bother you!
On Wed, Jun 14, 2023 at 11:01:57PM +0800, joeyli via openSUSE Factory wrote:
On Mon, Jun 12, 2023 at 06:26:06PM -0000, Bruno Pitrus wrote:
master branch of openSUSE Tumbleweed kernel Is it enabled in upstream? What problem would be it for you to ship an UNSIGNED kernel that has all the SUSE patches EXCEPT lockdown? You already ship kernel-vanilla, and AFAIK it does not have lockdown.
Mainline kernel has lockdown function but it didn't connect with the secure boot switch in firmware. Like other big distros (Fedora, Ubuntu, Leap/SLE), We put downstream patch to Tumbleweed kernel to connect lockdown-integrity mode with secure boot.
About kernel-vanilla, a bsc#1209008 be created (I am not sure that it's public bug). We will ship unsigned kernel-vanilla without lockdown.
Currently we do not have a SUSE-patched unsigned Tumbleweed kernel. We need a new kernel flavor against this. I don't know who has power to do the decision.
In the systemd-boot with unified kernel image (UKI) case, community has voice that he wants to have a unsigned kernel with SUSE patches, and the kernel will not be locked-down. Because they want to produce UKI image and sign it by their personal key. SUSE will not be responsible for the integrity or verifiction of their self-signed UKI image. User should enroll their key to db by UEFI firmware UI manually.
Could you please consider to create a openSUSE Tumbleweed Jira against this requirement? I think that we need a new kernel flavor for Tumbleweed to fill this requirement.
This should be possible to do with config.addon mechanism - that is create a link of kernel-source and add an extra config file that disables the lockdown.
As this is an unnofficial kernel anyone can create a link in a project of their choice.
I didn't try it. But looks that it's a good idea for anyone uses UKI solution. Because user will sign EFI image by himself, he doesn't need SUSE signature. And user can also change the kernel config to remove lockdown function. Thanks! Joey Lee
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 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
Il 12/07/23 03:16, Jiri Slaby ha scritto:
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,
May be this is a different topic but just to return on some issue related to new kernels: so far suspend on my i915 keeps nonworking. Regards, -- Marco Calistri Build: openSUSE Tumbleweed 20230709 Kernel: 6.3.9-1-default - XFCE: (4.18.3)
participants (13)
-
Andrei Borzenkov -
Bjoern Voigt -
Bruno Pitrus -
Carlos E. R. -
Christian Goll -
Jiri Slaby -
Joe Salmeri -
joeyli -
Marco Calistri -
Michal Suchánek -
Stefan Dirsch -
Takashi Iwai -
Vlastimil Babka