Skip to main content

UEFI Secure Boot with ESXi 6.5

UEFI Secure Boot:

UEFI, or Unified Extensible Firmware Interface, is a replacement for the traditional BIOS firmware. In UEFI, Secure Boot is a “protocol” of the UEFI firmware. UEFI Secure boot ensures that the boot loaders are not compromised by validating their digital signature against a digital certificate in the firmware.

UEFI can store whitelisted digital certificates in a signature database (DB). There is also a blacklist of forbidden certificates (DBX), a Key Exchange Keys (KEK) database and a platform key. These digital certificates are used by the UEFI firmware to validate the boot loader. 

Boot loaders are typically cryptographically signed and their digital signature chains to the certificate in the firmware.The default digital certificate in almost every implementation of UEFI firmware is a x509 Microsoft UEFI Public CA cert.

Most of the UEFI implementations also allows the installation of additional certificate in the UEFI firmware and UEFI would validate boot loader against that certificate.

UEFI Secure Boot in ESXi 6.5:
With the release of vSphere 6.5, ESXi 6.5 has adopted support for UEFI Secure boot. UEFI Secure boot ensures that ESXi server boots with signed boot loader that is validated by UEFI Firmware and also ensures that unsigned code does not run on hypervisor.

ESXi is comprised of components like boot loader, the VM Kernel, Secure Boot Verifier and VIBs. Each of these components is cryptographically signed.

Image: VMware
The boot process of ESXi 6.5 with UEFI Secure Boot:
  • Host is Powered On.
  • UEFI Firmware validates the ESXi Boot Loader against the Microsoft digital certificate in the UEFI firmware.
  • ESXi Boot Loader validates the kernel against the VMware digital certificate in the Boot Loader.
  • Kernel runs the Secure Boot Verifier.
  • Secure Boot Verifier validates each VIB against the VMware digital certificate in the Secure Boot Verifier.
  • Management applications (DCUI, hostd, etc) now run on the ESXi host.

The ESXi boot loader is signed with the Microsoft UEFI Public CA cert. This ensures that standard UEFI Secure Boot firmware can validate the VMware boot loader. 

The boot loader code contains a VMware public key. This VMware key is used to validate the VM Kernel and a small subset of the system that includes the Secure Boot Verifier, used to validate the VIBs.

The VMKernel itself is cryptographically signed using the VMware public key. The boot loader validates the kernel using the VMware public key it has. The first thing the VMKernel runs is the Secure Boot Verifier.

The Secure Boot Verifier validates every cryptographically signed VIB against the VMware public key. A VIB (TAR g-zipped file) comprises, an XML descriptor file and a digital signature file. When ESXi boots, it creates a file system in memory that maps to the contents of the VIBs. If the file never leaves the cryptographically signed “package” then you don’t have to sign every file, just the package.

Prerequisites to enable UEFI Secure Boot:
  • Verify that the hardware supports UEFI secure boot by default or if any firmware upgrade is required.
  • Verify that all VIBs are signed with an acceptance level of at least PartnerSupported. If you include VIBs at CommunitySupported level, you cannot use secure boot.
Enabling UEFI Secure boot post upgrade to ESXi 6.5:

We can call a validation script located on ESXi host to ensure that we can enable Secure Boot after upgrade to 6.5:

/usr/lib/vmware/secureboot/bin/secureBoot.py -c

The output either includes "Secure Boot can be enabled" or "Secure boot cannot be enabled".
Labels:

Comments

Post a Comment

Popular posts from this blog

Dell EMC VxRail – VMware Virtual SAN Stretched Cluster

Logical Diagram of VMware vSAN Stretched Cluster Physical Diagram of VMware vSAN Stretched Cluster Last week I deployed a test environment of VMware vSAN Stretched Cluster which is running on Dell EMC VxRail Appliance. In this post we will describe how to setup VMware vSAN Stretched Cluster on Dell EMC VxRail Appliance. Above figure is the high level of physical system diagram. In site A/B there are six VxRail Appliances and two 10GB Network Switch which are interconnected by two 10GB links, and each VxRail Appliance has one 10GB uplink connects to each Network Switch. In site C, there are one vSAN Witness host and one 10GB Network Switch. For the details of configuration of each hardware equipment in this environment, you can reference the followings. Site A (Preferred Site) 3 x VxRail E460 Appliance Each node includes 1 x SSD and 3 x SAS HDD, 2 x 10GB SFP+ ports 1 x 10GB Network switch Site B (Secondary Site) 3 x VxRail E460 Appliance Each node includes 1 x SSD and...
1 comment
Read more

Console Mouse Not Working in Windows 2012 VMs

I recently ran into some problems while deploying a Windows Server 2012 R2 VM in my vSphere 6.5 U2 lab. I’ve come to expect that the console mouse response is going to be terrible until VMware Tools is installed, but for some odd reason I had no mouse control whatsoever. Thinking it may be a quirk of the Web Console, I tried both the Remote Console and the HTML5 client to no avail. The VM appeared to be healthy and would register keyboard input, but the motion of the mouse cursor was erratic or the cursor would not move at all. Thinking that I just needed to battle on and get Tools installed, I attempted to use the keyboard for this purpose – what a chore. You think it would have been easy, but the installer kept losing focus and falling behind other open windows. Many of the windows keyboard shortcuts I’d normally use were not functioning because they register on my laptop – not in the console. I couldn’t RDP to the VM either because the NIC needed to be configured with a vali...
Post a Comment
Read more

Certificate Error During Datastore Upload

“The operation failed for an undetermined reason. Typically, this problem occurs due to certificates that the browser does no trust. If you are using self-signed or custom certificates, open the URL below in a new browser tab and accept the certificate, then retry the operation.” In my case, the URL that it listed was to one of my ESXi hosts in the compute-a cluster called Clu-1 . The error then goes on to reference VMware KB 2147256 . It may seem odd that the vSphere Client would be telling you to visit a random ESXi host’s UI address when you are trying to upload a file via vCenter. But if you stop to think about it for a second, vCenter has no access whatsoever to your datastores. Whether you are trying to create a new VMFS datastore, upload a file or even just browse, vCenter must rely on an ESXi host with the necessary access to do the actual legwork. That ESXi host then relays the information back through the Web Client. vCenter Server will broker th...
Post a Comment
Read more