Secure boot and Nvidia

barney · 2023-12-05 22:41:35

I have laptop with Nvidia graphics card. I want to install the nvidia package. I have two questions.
1. The wiki for Intel graphics states that kms should be enabled. The wiki for Nvidia states the opposite, kms should be removed. I don't know what to do?
2. I am using sbctl for secure boot. I don't know which module should be signed (there are several of nvidia modules). Also, modules should be signed after every update of linux package and nvidia package. I know that this can be done with pacman hook, bat the location of the modules is not fixed, it depends of the version of the kernel. Is there a way to find out the version of the kernel within the pacman hook?

seth · 2023-12-06 12:48:07

kms is always enabled, you're referring to the KMS hook.
The reason to disable it is so that you don't end up w/ the nouveau modules in the initramfs (though given nvidia and esp. the modprobe.conf that blacklists nouveau ends up in the initramfs, nouveau becomes inert there as well)
=> You can remove the kms hook as advised and explicitly add "i915" to the MODULES array.

Afaik signing OOT modules will require you to build your own kernel, https://wiki.archlinux.org/title/Signed_kernel_modules

Head_on_a_Stick · 2023-12-06 17:15:12

seth wrote:

Afaik signing OOT modules will require you to build your own kernel, https://wiki.archlinux.org/title/Signed_kernel_modules

That has nothing to do with Secure Boot.

@OP: see https://bbs.archlinux.org/viewtopic.php?id=279974 & https://bbs.archlinux.org/viewtopic.php … 7#p2021657 (but the Debian sign-file script has been removed).

seth · 2023-12-06 18:33:42

So the plan is to sign the kernel and some files w/ your secureboot key but then not lockdown the kernel and allow full access to the kernel from userspace?

Head_on_a_Stick · 2023-12-06 18:37:17

If SecureBoot is enabled unsigned out of tree kernel modules cannot be loaded.

Last edited by Head_on_a_Stick (2023-12-06 18:37:31)

seth · 2023-12-06 18:51:15

Unsigned how?
If OOT modules that are not signed w/ the kernel key cannot be loaded the link in #2 becomes kinda relevant.
If OOT modules that are not signed w/ the secureboot key cannot be loaded, but the kernel is otherwise not locked down, secure boot isn't all that "secure" anymore.

espritlibre · 2023-12-06 19:35:54

i have secure boot enabled, but lockdown disabled (for another reason). loading the nvidia module does taint the kernel, but loads and work just fine with prime-run on a hybrid systme. i'm not signing OOT modules, just kernel and efi stuff. have a look:

kernel: nvidia: loading out-of-tree module taints kernel.
kernel: nvidia: module license 'NVIDIA' taints kernel.
kernel: nvidia: module verification failed: signature and/or required key missing - tainting kernel
kernel: nvidia: module license taints kernel.
kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 510
kernel: nvidia 0000:03:00.0: enabling device (0006 -> 0007)
kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module  545.29.06  Thu Nov 16 01:59:08 UTC 2023
kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  545.29.06  Thu Nov 16 01:47:29 UTC 2023
kernel: nvidia_uvm: module uses symbols nvUvmInterfaceDisableAccessCntr from proprietary module nvidia, inheriting taint.
(udev-worker)[505]: nvidia: Process '/usr/bin/bash -c '/usr/bin/mknod -Z -m 666 /dev/nvidiactl c $(grep nvidia-frontend /proc/devices | cut -d \  -f 1) 255'' failed with exit code 1.
(udev-worker)[505]: nvidia: Process '/usr/bin/bash -c 'for i in $(cat /proc/driver/nvidia/gpus/*/information | grep Minor | cut -d \  -f 4); do /usr/bin/mknod -Z -m 666 /dev/nvidia${i} c $(grep nvidia-frontend /proc/devices | cut -d \  -f 1) ${i}; done'' failed with exit code 1.
(udev-worker)[505]: nvidia_modeset: Process '/usr/bin/bash -c '/usr/bin/mknod -Z -m 666 /dev/nvidia-modeset c $(grep nvidia-frontend /proc/devices | cut -d \  -f 1) 254'' failed with exit code 1.
(udev-worker)[475]: nvidia: Process '/usr/bin/bash -c '/usr/bin/mknod -Z -m 666 /dev/nvidiactl c $(grep nvidia-frontend /proc/devices | cut -d \  -f 1) 255'' failed with exit code 1.
(udev-worker)[475]: nvidia: Process '/usr/bin/bash -c 'for i in $(cat /proc/driver/nvidia/gpus/*/information | grep Minor | cut -d \  -f 4); do /usr/bin/mknod -Z -m 666 /dev/nvidia${i} c $(grep nvidia-frontend /proc/devices | cut -d \  -f 1) ${i}; done'' failed with exit code 1.
systemd-modules-load[373]: Inserted module 'nvidia_uvm'
kernel: [drm] [nvidia-drm] [GPU ID 0x00000300] Loading driver
kernel: nvidia-uvm: Loaded the UVM driver, major device number 508.
kernel: [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:03:00.0 on minor 1
systemd[1]: Starting NVIDIA Persistence Daemon...
nvidia-persistenced[1166]: Started (1166)
systemd[1]: Started NVIDIA Persistence Daemon.
gnome-shell[1825]: Added device '/dev/dri/card1' (nvidia-drm) using atomic mode setting.
gnome-shell[2679]: Added device '/dev/dri/card1' (nvidia-drm) using atomic mode setting.

Head_on_a_Stick · 2023-12-06 19:50:13

In which case I apologise for the misinformation. I did have failures loading unsigned custom modules with SecureBoot enabled but it must have been for a different reason. I don't use NVIDIA, obviously, so I will stay out of these threads in future. Sorry again.

seth · 2023-12-06 20:01:29

espritlibre's account is interesting, concerning and ridiculing the entire secureboot approach (at least w/o lockdown)
If you can load random, completely unsigned kernel modules into the kernel space at runtime, you're now running a different kernel from the one that was ever signed for secureboot and you can just as much disable secureboot

@HoaS, this also concerns eg. virtualbox, if you've SB enabled, you could just try to load one of those.

espritlibre · 2023-12-06 21:01:43

seth wrote:

espritlibre's account is interesting, concerning and ridiculing the entire secureboot approach (at least w/o lockdown)
If you can load random, completely unsigned kernel modules into the kernel space at runtime, you're now running a different kernel from the one that was ever signed for secureboot and you can just as much disable secureboot

this is not completely true, on a system with fde + encrypted boot the efi files are somewhat unprotected. with secure boot they're protected. i'm travelling a lot and most of the time i have my personal notebook with me, i'm more concerned about evil maids when leaving this laptop unattended for long perdiods of time at the hotel.
i'm not happy with the status quo. i'm disabling lockdown, in order for throttled can do it's job, my cpu gets massively throttled otherwise. i haven't found another solution for this yet, but i'm doing progress.

Head_on_a_Stick · 2023-12-06 21:05:15

I can load the xone module for my game controller with SecureBoot enabled. I'm sure that wasn't possible previously but I must be wrong.

barney · 2023-12-06 22:47:16

I have found this link Signing modules build with dkms. The most relevant part is the last two comments.
I don't know if this mechanism ( with framework.conf edited, with $sign_file, $mok_signing_key and $mok_certificate set to correct values) is working with arch linux package and nvidia-dkms package.
The problem I cannot test this is that sbctl cannot be used to sign modules (I don't know why, I suppose that only efi binaries can be signed with sbctl).
If there is a way to sign the modules with the keys generated by sbctl please inform me. I will be able to test the method described in the previous link.
I know that this method (described in the previous link, not in the comments) is working in Debian. I don't know if it can be modified for arch linux.

seth · 2023-12-07 07:49:34

From #7 and #11 you don't have to sign anything, but the kernel modules *are* a (compressed) ELF binary, ie. to test this simply "zstd -d nvidia.ko.zst", but oc you want the signing to happen during the dkms build before the module gets compressed and I'd assume that the dkms config entry will provide exactly that.

barney · 2023-12-07 20:52:20

seth wrote:

From #7 and #11 you don't have to sign anything

If I enable module.sig_enforce=1 kernel parameter then the modules have to be signed. The problem is that Arch developers decided that only modules signed with the pair of keys generated at compile time will be accepted, modules signed with keys enrolled in the UEFI firmware are denied. I don't know the logic behind this decision, but it is against the logic of the secure boot.

seth · 2023-12-07 21:11:49

That's https://wiki.archlinux.org/title/Signed … mmand_line which as pointed out by HoaS is NOT (directly) related to secure boot (though see the discussion above and the security implications when not using signed kernel modules) and this is not a decision by "Arch developers" but how kernel module signing works and certainly has nothing to do with "the logic of the secure boot"

barney · 2023-12-07 21:36:09

seth wrote:

... and certainly has nothing to do with "the logic of the secure boot"

OK, lets say that this has nothing to do with secure boot.
Kernel image or UKI is signed with key pairs enrolled in UEFI firmware and only loaded if the keys match, why not to allow loading, by the kernel, of modules signed with this keys, when in first place we trusted them to load the kernel itself?
On Debian, Fedora (and I suppose on other distribution) method with sign_file, mok_signing_key and mok_certificate work out of the box and modules that are not signed with this keys are not loaded.

seth · 2023-12-07 21:42:56

Kernel image or UKI is signed with key pairs enrolled in UEFI firmware

this has nothing to do with secure boot

modules that are not signed with this keys are not loaded

HoaS wrote:

I can load the xone module for my game controller with SecureBoot enabled. I'm sure that wasn't possible previously but I must be wrong.

There's probably been some change in how kernel modules are handled vs. secure boot, but you're still looking at the wrong mechanics.

One aspect I could imagine is that secure boot w/o a kernel lockdown is of questionable benefit and assuming that you're requiring signed modules for a locked down kernel anyway, further, secureboot related, signing is pointless overhead.

Edit: https://bugs.archlinux.org/task/75102

Last edited by seth (2023-12-07 21:52:06)

Arch Linux

#1 2023-12-05 22:41:35

Secure boot and Nvidia

#2 2023-12-06 12:48:07

Re: Secure boot and Nvidia

#3 2023-12-06 17:15:12

Re: Secure boot and Nvidia

#4 2023-12-06 18:33:42

Re: Secure boot and Nvidia

#5 2023-12-06 18:37:17

Re: Secure boot and Nvidia

#6 2023-12-06 18:51:15

Re: Secure boot and Nvidia

#7 2023-12-06 19:35:54

Re: Secure boot and Nvidia

#8 2023-12-06 19:50:13

Re: Secure boot and Nvidia

#9 2023-12-06 20:01:29

Re: Secure boot and Nvidia

#10 2023-12-06 21:01:43

Re: Secure boot and Nvidia

#11 2023-12-06 21:05:15

Re: Secure boot and Nvidia

#12 2023-12-06 22:47:16

Re: Secure boot and Nvidia

#13 2023-12-07 07:49:34

Re: Secure boot and Nvidia

#14 2023-12-07 20:52:20

Re: Secure boot and Nvidia

#15 2023-12-07 21:11:49

Re: Secure boot and Nvidia

#16 2023-12-07 21:36:09

Re: Secure boot and Nvidia

#17 2023-12-07 21:42:56

Re: Secure boot and Nvidia

Board footer