Hyper-V 2016 Support for Linux Secure Boot

Microsoft has been hard at work adding support for Linux to its server products. Specific to Hyper-V 2016 is the extension of Secure Boot to include many Linux distributions. Due to the technological nature of both Linux and Secure Boot, not every distribution will work, and it will be possible for legitimate modifications to supported distributions to prohibit Secure Boot.

How Do I Know if My Linux Distribution is Supported by Hyper-V Secure Boot?

Microsoft has a TechNet article set devoted to Linux on Hyper-V. There are links at the bottom of the primary article and in the Table of Contents that jump to distribution-specific articles that outline the available feature sets. Most CentOS/RHEL, SUSE and Ubuntu users hoping for Secure Boot support will like what they find. Most users of other Linux distributions and FreeBSD will be disappointed. I assume that Microsoft will at least attempt to add support to other distributions, but I’m unaware of the effort and politics involved, so I can’t tell you when or even if you should ever expect your distribution to attain that check mark. I would say that it is unlikely that Secure Boot support will be backported to older versions of distributions that currently have it (ex: 14.04 and later of Ubuntu have Secure Boot support — don’t expect to ever see 12.04 receive it).

Unlike some other features, you can’t just hope that a close-but-not-quite distribution or fork will enjoy Secure Boot just because of similarities or common ancestry with a supported distribution. Secure Boot technology is very exacting, for good reason.

What is Secure Boot?

Secure Boot is a system designed to ensure that an operating system’s loading utility has not been tampered with. This can be an effective preventive measure against malicious code being injected into a computer’s startup cycle ahead of the operating system.

It is possible to have a very deep (read as: boring) technical discussion about Secure Boot. We’ll save all of that for a whitepaper and hit only the highlights. To understand it at all, you need to think about something that everyone that uses a computer sees every day but almost never thinks about: the boot process. From a very high level, this is the boot process:

1. The hardware is energized.
2. Control is held by the basic input/output system (BIOS). It validates core hardware: CPU, memory, ROMs, other parts that you might not even know exist and probably don’t care about.
3. BIOS locates I/O systems that are boot options. It starts with the first in its boot order list, looking for an OS loader in predefined locations. For a hard drive, that’s sector 0. It proceeds through each device until it finds one, ending in an error condition out with some sort of “No bootable media found” message if no one has an OS loader.
4. If an OS loader is found, BIOS loads it into memory and sends it to the CPU for processing. The BIOS essentially relinquishes control.
5. The OS loader starts the operating system.

This is a very simplified view, of course, but works well enough to get the point across. The security issue appears at step 4. As long as the located OS loader responds, BIOS considers its work to be finished and exits the scene. It neither knows nor cares what happens at that point. That’s a perfect attack vector for malicious software. The most common type of software to be concerned with is “root kits”. These are software shims, typically malicious, that sit between the BIOS and the operating system. Because they are above the OS, it cannot detect the presence of the root kit. The root kit has unfettered access to any and all I/O operations. It can operate any code and intercept any keystrokes.

Enter the Unified Extensible Firmware Interface (UEFI). It’s still a BIOS at heart, but it’s a substantial redesign, and it takes into account issues such as these. Now, instead of looking at sector 0 on a hard drive (or something pretending to be a hard drive for boot purposes) and just running whatever code it finds there, UEFI knows how and where to look for specific files. It also has the ability to perform some processing beyond simply feeding the destination contents into the CPU.

Secure Boot combines the enhanced boot and processing capabilities with the cryptographic capabilities of UEFI. Encryption keys are stored in firmware. When UEFI is asked to start an OS loader, it can check the cryptographic signature of that OS loader, if any, against the signatory keys that it knows about. If the image has been signed with a verifiable key, UEFI will allow it to start. Otherwise, it halts the entire boot process with a message. In Hyper-V, these are the some of the messages that you might see when no signature or an invalid signature is found:

Secure Boot Improperly Signed Image

The first entry is the most important (The image’s hash and certificate are not allowed). It is telling you that UEFI did find an OS loader, and the loader is digitally signed, but that it does not match the approved list in the UEFI firmware.

What are the Requirements for Linux Secure Boot on Hyper-V?

Starting with the above knowledge and adding a few points, we can quickly determine a requirements list:

• Hyper-V 2016 — can be Hyper-V Server 2016, Windows Server 2016 with the Hyper-V role, or Client Hyper-V in Windows 10
• A supported distribution and version. You can quickly determine support for yours by checking the previously mentioned Linux support article set. In technical terms, the distribution’s boot loader must be digitally signed and its signature must be verifiable by the information stored in Hyper-V’s UEFI key repository.
• The distribution must be installed into a Generation 2 virtual machine.
• Secure Boot must be enabled in the virtual machine.
• The selected Secure Boot template must be the Microsoft UEFI Certificate Authority.

How Do I Enable Linux Secure Boot in Hyper-V Manager?

You’ll need the Windows 10/Windows Server 2016 version of Hyper-V Manager for this to work.

1. In Hyper-V Manager, ensure that the virtual machine is off.
2. Open the properties sheet for the Linux VM.
3. Switch to the Security tab.
4. Check the Enable Secure Boot checkbox. If you do not have this checkbox, this is a Generation 1 virtual machine.
5. Change the template to Microsoft UEFI Certificate Authority.
6. Click OK. The next time the virtual machine is booted, Secure Boot will be in effect. If all is well, you won’t notice anything.

Hyper-V Manager Secure Boot Settings

If Shielding has been enabled, all of these options will be greyed out. You’ll need to temporarily disable shielding in order to change the option OR you can use PowerShell.

How Do I Enable Linux Secure Boot in PowerShell?

It’s an almost simple one-liner in PowerShell:

Set-VMFirmware -VMName dtlinux -EnableSecureBoot On -SecureBootTemplate 'MicrosoftUEFICertificateAuthority'

What makes it “almost” simple is that you need to know the name of the template that you want. Ack! Typing!! But wait:

Get-VMHost | select SecureBootTemplates

The host knows which templates it has loaded. Copy/paste from there into the SecureBootTemplate parameter of Set-VMFirmware.

Whereas the GUI will not allow changes to be made to the template while shielding is enabled, the PowerShell cmdlet will work whether shielded is enabled or not. However, the virtual machine must still be in the Off state.

Can I Change the Templates or Update the Keys?

Simply put, no, you cannot. If just anyone could change the templates and keys, then just anyone could change the templates and keys. The system’s techniques for determining whether or not a key update is authorized is highly restrictive, out of necessity.

What Are the Risks and Drawbacks of Secure Boot?

Secure Boot is a good solution, but not a perfect one. Its primary strength lies in the fact that most attacks are going to be leveled at trusting users of a targeted operating system. Only the most sophisticated attackers will go after UEFI and the Secure Boot mechanism. Locking your doors keeps out most criminals, not because locks are perfect, but because most criminals are looking for easy targets. Enabling Secure Boot is a lock against most root kits and other such malware. That said, there are several things to be aware of with Secure Boot:

• The number one biggest problem with Secure Boot is the exact same number one biggest problem with root kits: the user. Malware does its best work when it has a compliant user willing to ignore warning signs. In this case, the user is you, and unfortunately, you have the full support of the community to do things that you should not do. 99% of the time, when someone reports a Secure Boot failure, the very first answer, usually followed by several other people with the same suggestion, is: “turn off Secure Boot“. Hmm. If your boot code is compromised by a root kit, you’ll have a Secure Boot failure. Think about that for a minute, then consider what the proposed “solution” would mean.
  Don’t just blindly disable Secure Boot. If Secure Boot has always been configured properly and it has never worked with a specific virtual machine and you can prove that at least one item on the requirements list has not been satisfied, then your answer is to turn off Secure Boot. Otherwise, you should assume that Secure Boot has done its job and the virtual machine is compromised.
• Microsoft accidentally published a key set that will validate any signed OS loader code. Oops. They’ve since issued revocations, but that is not a perfect solution.
• It’s difficult, but not quite impossible to forge keys and forcefully update Hyper-V’s UEFI key lists. Any system that has even one path for a legitimate update provides at least one path for an unauthorized update.
• Secure Boot is an event, not a state. It cannot prevent your OS loader from becoming invalidated or corrupted. It cannot stop you from replacing a known good and validated boot loader with a wonderful but unsigned boot loader. All it can do is stop unrecognized code from running.