System Capabilities Supported by vGPU

Secure boot is a security standard that ensures only trusted software, such as signed operating systems, firmware, and drivers, can execute during the boot process. In virtualized environments, secure boot protects the integrity of the virtual machines (VMs), ensuring that only trusted OS and software are loaded. This is particularly critical for sensitive workloads or environments requiring GPU acceleration, such as AI/ML or graphics processing, by ensuring the VM operates in a secure environment. In addition, it improves stability, ensuring that only compatible and verified drivers are used, reducing the risk of system crashes. Secure boot can help organizations meet regulatory and compliance requirements for secure computing environments.

Secure boot requires GPU drivers to be properly signed for compatibility. Without proper signing, the VM may fail to recognize the GPU or prevent the driver from loading, impacting acceleration capabilities. Unsigned or improperly signed drivers will prevent the system from booting or operating securely.

For Linux guest VMs, NVIDIA provides a procedure to sign guest drivers, ensuring compatibility with secure boot environments. Detailed instructions on signing NVIDIA drivers for Linux can be found here. The procedure applies to both regular Linux drivers and vGPU guest drivers. Follow the steps outlined in the documentation to sign and deploy your drivers in a secure boot-enabled environment.

Secure boot operates by verifying cryptographic signatures against trusted keys stored in firmware. For virtual machines:

1. The hypervisor provides secure boot capabilities as part of its VM configuration.

2. The VM must use an operating system signed by the OS vendor.

3. The hypervisor’s secure boot mechanism verifies driver signatures, ensuring that only properly signed GPU drivers are loaded.

4. The hypervisor’s secure boot mechanism validates the OS during the boot process using vendor-provided keys.

This requires OS vendors to sign their bootloaders and kernels with approved secure boot keys, ensuring compatibility with hypervisor environments. Hypervisors must also support secure boot natively, and not all platforms or guest operating systems provide seamless compatibility. Another limitation is the configuration complexity when deploying secure boot in environments with diverse OS needs, as administrators may need to manually import and manage custom keys. Additionally, while secure boot has minimal performance overhead, enabling it may slightly increase VM boot times.

When deploying secure boot, using supported operating systems pre-signed by their vendors, such as Microsoft-signed Windows distributions or Canonical-signed Ubuntu builds, is essential. Sticking to official distributions reduces configuration complexity and ensures compatibility with the hypervisor. Testing VM boot processes after enabling secure boot is also crucial to verify proper key signing and functionality, particularly for workloads relying on vGPU features. Updating the hypervisor firmware and GPU drivers further ensures smooth compatibility and mitigates security risks. For environments requiring custom OS builds administrators should prepare to sign bootloaders and drivers with custom keys that are compatible with the hypervisor’s secure boot framework.

Consult with your virtualization platform vendor or one of their partners to verify whether their platform supports secure boot and what VM operating systems are supported.