DKMS Module Signature Enforcement
Lab.franklin compute nodes rely on several out-of-tree kernel modules (proprietary NIC drivers, custom crypto accelerators for node901's Jetson platform). These must be signed before Secure Boot enforcement is enabled:
- Signing key generation: Created a Machine Owner Key (MOK) pair using
openssl req -newkey rsa:4096 with X.509 v3 certificate format suitable for DKMS signing.
- Module signing workflow: Each signed module is processed via
kmodsign sha256 /path/to/signing.key /path/to/signing.cert modules.ko, producing a detached .sig file alongside the original .ko.
UEFI Secure Boot MOK Enrollment
The MOK public key was enrolled in the UEFI shim's Machine Owner Key store on each host:
- skynet, chonk: Remote enrollment via iPXE-booted mokutil utility during first boot post-signing.
- stargate: Direct console enrollment using UEFI shell's
MokManager.efi (physical access available).
- wonderland: Enrollment pending — physical console access blocked until the key injection gate is resolved (same blocker as node3).
Enforcement Status by Host
| Host | MOK Enrolled | Secure Boot Active | All Modules Signed? |
|---|
| skynet | Yes | Yes | Yes (5/5 modules) |
| chonk | Yes | Yes | Yes (8/8 modules) |
| stargate | Yes | Enforcing | In progress (7/9 modules) |
| wonderland | Pending | No (legacy boot) | N/A |
The remaining stargate modules (two proprietary NIC drivers for Intel E810 series) require vendor-signed certificates, which are currently being negotiated with the OEM. Until those keys arrive, stargate's Secure Boot enforcement is running in warn-only mode — it logs unsigned module load attempts to syslog but does not block them.