The Signing Certificates Are Not Installed Nvidia Windows 7
Leana Eckes
UEFI Secure Boot is a feature of the Unified Extensible Firmware Interface (UEFI) specification. The feature defines a new interface between the operating system and firmware/BIOS. This feature is available in the NVIDIA BlueField-2 and above.
When enabled and fully configured on the DPU, UEFI Secure Boot helps the Arm=based software running on top of UEFI resist attacks and infection from malware. UEFI Secure Boot detects tampering with boot loaders, key operating system files, and unauthorized option ROMs by validating their digital signatures. Malicious actions are blocked from running before they can attack or infect the system.
UEFI Secure Boot works as a security gate. Code signed with valid keys (whose public key/certificates exist in the DPU) gets through the gate and executes while blocking and rejecting code that has either a bad or no signature.
Signing binaries is complex as you must create X.509 certificates and enroll them in UEFI or shim which requires a fair amount of prior knowledge of how secure boot works. For that reason, BlueField secured platforms are shipped with all the needed certificates and signed binaries (which allows working seamlessly with the first use case in the table above).
As part of having UEFI secure boot enabled, the UEFI databases are populated with NVIDIA self-signed X.509 certificates. The Microsoft certificate is also installed into the UEFI database to ensure that the Ubuntu distribution can boot while UEFI secure boot is enabled (and generally any suitable OS loader signed by Microsoft).
Signing binaries for UEFI secure boot is complex as you must create X.509 certificates and enroll them in UEFI or shim which requires a fair amount of prior knowledge of how secure boot works. See the processes used to enroll keys and to sign UEFI binaries in the rest of this document.
One option to boot custom binaries on a DPU is to sign the OS loader (shim) by Microsoft following the Microsoft guidelines which are updated and maintained by Microsoft. The certificates/keys must be embedded within the shim OS loader so it may boot, in addition the custom Kernel binary image and the custom Kernel modules must be signed accordingly.
In this option, the NVIDIA db certificates should remain enrolled. This is due to the out-of-tree kernel modules and drivers (e.g., OFED) provided by NVIDIA which are signed by NVIDIA and authenticated by this NVIDIA certificate in the UEFI.
Signing binaries with Microsoft is a process the involves lead time which must be taken into consideration. This course of action requires testing to making sure the complied BFB image including the signed Microsoft bootloader works properly.
To boot a custom kernel or load a custom module, you must create a MOK key pair. The newly created MOK key must be an RSA 2048-bit. The private part is used for signing operations and must be kept safe. The public X.509 key certificate in DER format must be enrolled within the shim MOK list.
Note that kernel module signing requires a special configuration. For example, the extendedKeyUsage field must show an OID of 1.3.6.1.4.1.2312.16.1.2. That OID informs shim that this is meant to be a module signing certificate.
To create the capsule files, execute the mlx-mkcap script. After BlueField software installation, the script can be found under /lib/firmware/mellanox/boot/capsule/scripts. This script generates a capsule file to supply the key certificates to UEFI and enables UEFI secure boot:
The resulting capsule file, EnrollYourKeysCap, can be downloaded to the BlueField file system to initiate the key enrollment process. From the the BlueField console execute the following command then reboot:
If the X.509 certificate attributes (commonName, etc.) are configured properly, you should see your key certificate information in the result output. In this example, two custom keys are visible to the kernel:
Note that --signer-key and --signer-cert are set so the capsule is signed. When UEFI secure boot is enabled, the capsule is verified using the key certificates previously enrolled in the UEFI database. It is important to use the old signing keys associated with the certificates in the UEFI database to sign the capsule. The new key certificates are intended to replace the existing key certificates after capsule processing. Once the UEFI database is updated, the new keys must be used to sign the newly created capsule files.
This chapter provides instructions for installing the NVIDIAdriver. Note that after installation, but prior to using thedriver, you must complete the steps described in Chapter 6,Configuring X for the NVIDIA Driver. Additional detailsthat may be helpful for the new Linux user are provided in Appendix I,Tips for New Linux Users.
Before you begin the installation, exit the X server andterminate all OpenGL applications (note that it is possible thatsome OpenGL applications persist even after the X server hasstopped). You should also set the default run level on your systemsuch that it will boot to a VGA console, and not directly to X.Doing so will make it easier to recover if there is a problemduring the installation process. See Appendix I,Tips for New Linux Users for details.
The .run file is a self-extractingarchive. When executed, it extracts the contents of the archive andruns the contained nvidia-installerutility, which provides an interactive interface to walk youthrough the installation.
nvidia-installer will also installitself to /usr/bin/nvidia-installer,which may be used at some later time to uninstall drivers,auto-download updated drivers, etc. The use of this utility isdetailed later in this chapter.
When the installer is run, it will check your system for therequired kernel sources and compile the kernel interface. You musthave the source code for your kernel installed for compilation towork. On most systems, this means that you will need to locate andinstall the correct kernel-source, kernel-headers, or kernel-develpackage; on some distributions, no additional packages arerequired.
After the correct kernel interface has been compiled, the kernelinterface will be linked with the closed-source portion of theNVIDIA kernel module. This requires that you have a linkerinstalled on your system. The linker, usually /usr/bin/ld, is part of the binutils package. Youmust have a linker installed prior to installing the NVIDIAdriver.
The installer will check for the presence of DKMS on yoursystem. If DKMS is found, you will be given the option ofregistering the kernel module with DKMS, and using the DKMSinfrastructure to build and install the kernel module. On mostsystems with DKMS, DKMS will take care of automatically rebuildingregistered kernel modules when installing a different Linuxkernel.
If nvidia-installer is unable toinstall the kernel module through DKMS, the installation will beaborted and no kernel module will be installed. If this happens,installation should be attempted again, without the DKMSoption.
Note that versions of nvidia-installer shipped with drivers beforerelease 304 do not interact with DKMS. If you choose to registerthe NVIDIA kernel module with DKMS, please ensure that the moduleis removed from the DKMS database before using a non-DKMS awareversion of nvidia-installer toinstall an older driver; otherwise, module source files may bedeleted without first unregistering the module, potentially leavingthe DKMS database in an inconsistent state. Running nvidia-uninstall before installing a driver usingan older installer will invoke the correct dkms remove command to clean upthe installation.
Due to the lack of secure storage for private keys that can beutilized by automated processes such as DKMS, it is not possible touse DKMS in conjunction with the module signing support built intonvidia-installer.
Some kernels may require that kernel modules becryptographically signed by a key trusted by the kernel in order tobe loaded. In particular, many distributions require modules to besigned when loaded into kernels running on UEFI systems with SecureBoot enabled. nvidia-installerincludes support for signing the kernel module before installation,to ensure that it can be loaded on such systems. Note that not allUEFI systems have Secure Boot enabled, and not all kernels runningon UEFI Secure Boot systems will require signed kernel modules, soif you are uncertain about whether your system requires signedkernel modules, you may try installing the driver without signingthe kernel module, to see if the unsigned kernel module can beloaded.
In order to sign the kernel module, you will need a privatesigning key, and an X.509 certificate for the corresponding publickey. The X.509 certificate must be trusted by the kernel before themodule can be loaded: we recommend ensuring that the signing key betrusted before beginning the driver installation, so that the newlysigned module can be used immediately. If you do not already have akey pair suitable for module signing use, you must generate one.Please consult your distribution's documentation for details on thetypes of keys suitable for module signing, and how to generatethem. nvidia-installer can generate akey pair for you at install time, but it is preferable to have akey pair already generated and trusted by the kernel beforeinstallation begins.
Once you have a key pair ready, you can use that key pair innvidia-installer by passing the keysto the installer on the command line with the --module-signing-secret-key and --module-signing-public-key options. As an example,it is possible to install the driver with a signed kernel module insilent mode (i.e., non-interactively) by running:
On UEFI systems with secure boot enabled, nvidia-installer willpresent a series of interactive prompts to guide users through themodule signing process. As an alternative to setting the key pathson the command line, the paths can be provided interactively inresponse to the prompts. These prompts will also appear whenbuilding the NVIDIA kernel module against a kernel which hasCONFIG_MODULE_SIG_FORCE enabled in its configuration, or if theinstaller is run in expert mode.
d3342ee215