You are not logged in.
So, I've been scratching my head a while now trying to figure out how to properly manage my module signing.
Basically it started with me compiling a custom kernel to patch the tpm_tis_core which is broken under Dell XPS 15 9560. Now whenever I'm booting my new kernel (based on linux-kernel) it refuses to load my DKMS compiled nvidia modules.
My setup is the following:
I have my own PK, KEK and db keys enrolled on my laptop. Upon kernel or microcode updates a new unified image is created based on systemd efistub which I'm booting directly from the UEFI boot manager interface.
My harddrives are encrypted with luks, where the key is contained inside my tpm module (hence why i had to patch the kernel in the first place).
Since I'm booting from a UEFI stub without shim in the middle I'm unable to enroll module signing keys into the Mok. I even tried to do it through MokManager directly which successfully enrolles the key, but it's not available through moklist and modprobe still fails with "Key was rejected by service".
So a couple of questions:
1. How does one manage module signing without the MokList? I can't seem to understand which keyrings are valid for integrity checking modules. .machine I do understand since it's populated by the MokList, but shouldn't platform populated keys such as db be okay as well since it's fine for validating my kernels integrity?
2. How the hell did I not have this problem with the mainline kernel? There are no changes to my Secure Boot setup, and PCR 0 and 7 are not changed since I didn't have to enroll a new luks key.
Last edited by root_op (2023-02-04 16:43:55)
Offline
Did you use DKMS before for your nvidia drivers, or just the nvidia package?
In any case I believe you're a bit out of luck, i.e. need to apply another bunch of kernel patches, to actually let the kernel load module signing keys from MOK, because as far as I'm aware it's not supported currently without shim, see https://github.com/Foxboron/sbctl/issues/52
Offline
nvidia used to compile through DKMS before I switched kernel as I used linux-hardened before.
As an experiment I reinstalled linux-hardened this morning and tried it out again, and lo and behold, it signed and loaded perfectly.
Here's the modinfo from nvidia on linux-hardened:
filename: /lib/modules/6.1.9-hardened1-1-hardened/updates/dkms/nvidia.ko.zst
firmware: nvidia/525.85.05/gsp_tu10x.bin
firmware: nvidia/525.85.05/gsp_ad10x.bin
alias: char-major-195-*
version: 525.85.05
supported: external
license: NVIDIA
srcversion: 6486826C11DE6850EA9AD88
alias: pci:v000010DEd*sv*sd*bc06sc80i00*
alias: pci:v000010DEd*sv*sd*bc03sc02i00*
alias: pci:v000010DEd*sv*sd*bc03sc00i00*
depends:
retpoline: Y
name: nvidia
vermagic: 6.1.9-hardened1-1-hardened SMP preempt mod_unload modversions RANDSTRUCT_6e72d88ab9c602e486a016263007673e35880a1f1650d6a8942c15605602305b
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key: 1B:84:13:80:26:C2:C3:25:3C:CC:27:5C:4E:73:E7:D6:C8:32:84:6E
sig_hashalgo: sha512
signature: 30:65:02:31:00:C2:04:75:12:81:7F:65:13:DF:10:95:70:37:9B:BE:
AF:A8:4F:63:59:A6:0F:7D:C4:EA:A0:46:A2:8C:72:B9:58:FA:A0:E2:
51:77:E1:7A:94:02:6D:13:14:3C:A3:5E:2D:02:30:17:8C:BB:5C:B1:
4A:75:10:67:F5:71:74:5C:15:DF:E6:E9:57:2E:95:EE:01:83:C2:BF:
4A:8B:B1:8A:C7:A1:2C:4B:50:CD:77:46:F0:67:BE:BA:EB:D8:B2:0F:
74:1F:18From the pacman log I can see that dkms ran as an ALPM hook after installing the kernel:
[2023-02-05T11:38:08+0100] [PACMAN] Running 'pacman -S linux-hardened linux-hardened-headers'
[2023-02-05T11:43:31+0100] [ALPM] transaction started
[2023-02-05T11:43:32+0100] [ALPM] installed linux-hardened (6.1.9.hardened1-1)
[2023-02-05T11:43:35+0100] [ALPM] installed linux-hardened-headers (6.1.9.hardened1-1)
[2023-02-05T11:43:35+0100] [ALPM] transaction completed
[2023-02-05T11:43:35+0100] [ALPM] running '30-systemd-update.hook'...
[2023-02-05T11:43:35+0100] [ALPM] running '60-depmod.hook'...
[2023-02-05T11:43:37+0100] [ALPM] running '70-dkms-install.hook'...
[2023-02-05T11:43:37+0100] [ALPM-SCRIPTLET] ==> dkms install --no-depmod nvidia/525.85.05 -k 6.1.9-hardened1-1-hardened
[2023-02-05T11:45:22+0100] [ALPM-SCRIPTLET] ==> depmod 6.1.9-hardened1-1-hardened
[2023-02-05T11:45:23+0100] [ALPM] running '90-mkinitcpio-install.hook'...So it looks as when dkms is run from the ALPM hook it signs modules perfectly fine. So I tried to dkms uninstall nvidia and reinstalling it, and now again nvidia won't load on linux-hardened because it's used the mok key:
filename: /usr/lib/modules/6.1.9-hardened1-1-hardened/updates/dkms/nvidia.ko.zst
firmware: nvidia/525.85.05/gsp_tu10x.bin
firmware: nvidia/525.85.05/gsp_ad10x.bin
alias: char-major-195-*
version: 525.85.05
supported: external
license: NVIDIA
srcversion: 6486826C11DE6850EA9AD88
alias: pci:v000010DEd*sv*sd*bc06sc80i00*
alias: pci:v000010DEd*sv*sd*bc03sc02i00*
alias: pci:v000010DEd*sv*sd*bc03sc00i00*
depends:
retpoline: Y
name: nvidia
vermagic: 6.1.9-hardened1-1-hardened SMP preempt mod_unload modversions RANDSTRUCT_6e72d88ab9c602e486a016263007673e35880a1f1650d6a8942c15605602305b
sig_id: PKCS#7
signer: DKMS module signing key
sig_key: 53:6C:06:7E:A3:EB:F2:A4:35:CF:3B:46:5C:BF:7D:9D:D8:22:8C:30
sig_hashalgo: sha512
signature: 4D:24:86:B4:F8:6D:29:3E:99:3A:8D:96:EB:34:E6:96:4C:66:8C:80:
B7:F9:7C:71:F8:00:E3:B0:AE:EF:6B:E7:F3:B3:63:88:63:7E:85:AA:
E4:4B:F0:BD:30:1F:AE:DA:73:42:A6:89:BC:EC:EA:58:53:11:55:E1:
6B:43:FB:1B:8E:EE:5E:93:F4:2E:DD:BC:53:D0:78:5D:23:7F:23:42:
88:01:6E:96:80:CC:F9:7F:F6:B1:8D:D2:65:34:9C:28:7E:1D:23:AB:
D9:44:DE:8A:23:32:E1:AB:8D:04:D7:A9:23:82:B3:99:56:40:77:21:
A7:60:0E:F8:55:AB:06:F5:28:D6:86:4E:06:FE:5E:13:90:27:F3:88:
EA:AD:72:58:17:4A:17:1C:E6:05:C1:33:DB:36:BD:63:DA:FA:5A:1C:
83:E3:B6:3B:14:6B:6B:8D:98:34:E5:9A:0C:08:71:88:93:73:B7:D6:
FD:F1:DE:20:F7:12:53:B4:0D:12:C5:68:95:98:54:C5:BE:1E:FB:DA:
3D:91:A3:1D:78:B8:8C:C4:6A:77:88:CF:07:CB:59:39:EA:BB:2C:39:
0E:FB:13:23:CF:37:F1:73:12:EC:E3:C8:6C:D0:F4:63:6D:68:8B:15:
11:6B:AF:08:29:CA:FB:F6:2D:C5:0A:54:C1:5B:BA:CBSo it does look as there's some magic happening somewhere in the ALPM hooks, which ain't working on my custom kernel. Any ideas?
Also thanks for the link, I'll follow up on those patches. It looks to me as it should be clarified on the wiki that MOK keys are unavailable if you're booting with efistub, since it's Shim specific and very confusing.
Offline