How does Linux Secure Boot affect Hyper-V 2016 VMs?
Linux Secure Boot can help ensure you're booting trusted OSes, but navigating different distributions and digital signatures can be challenging without these considerations.
Linux Secure Boot ensures that only trusted OSes -- those that contain a digital signature -- boot your system, which can protect against malware, rootkits and other threats.
Linux has made significant inroads into data centers. Adopters often use it to lower costs and lessen licensing headaches, while also providing ample support for a growing number of open source frameworks and workloads. The challenge with Linux is largely a matter of installing it on modern computers.
Most computers built since 2012 -- roughly around the release of Windows 8 -- employ Unified Extensible Firmware Interface (UEFI) firmware. UEFI firmware provides a versatile, modular design that enables firmware-makers to include many advanced features beyond those found in traditional BIOS. One such UEFI feature is Linux Secure Boot.
The goal of Linux Secure Boot is to ensure that only trusted OSes boot the system. OSes include a digital signature that Linux Secure Boot checks against. If the firmware's trusted device store includes the digital signature of the installed OS, the computer boots. If not, the computer won't boot. This is a method to prevent rootkits and other malware from infecting and altering the Windows Boot Manager.
Navigate Linux Secure Boot advantages and limitations
Linux Secure Boot is hardly a new idea, but Linux Secure Boot long omitted signatures for non-Windows OSes. Many Linux distributions weren't signed or included in the UEFI platform's Secure Boot.
The goal of Linux Secure Boot is to ensure that only trusted OSes boot the system.
In a traditional, physical PC, you couldn't then replace Windows with Linux. The system simply wouldn't boot -- at least not without UEFI errors. In a virtualized data center, this could prevent Hyper-V VMs that ran Linux as a guest OS from spinning up on a Windows and UEFI host server.
You could work around this problem by using a shim boot loader for major versions of Ubuntu, Fedora, openSUSE and Red Hat Enterprise Linux. The shim boot loader acted as a bridge between the OS and Linux Secure Boot to confirm the OS signature. This enabled the boot process to proceed.
The only other way to get around these boot errors and load an unsigned OS that the UEFI Linux Secure Boot didn't include was to disable the Linux Secure Boot feature in the firmware. Disabling such an important security feature was certainly not a best practice for an average user or enterprise data center.
With Windows Server 2016, UEFI firmware now includes a much larger stable of trusted signatures for major Linux distributions. The goal is to provide greater support for Linux use in Hyper-V guest VMs without the need to compromise security by disabling Linux Secure Boot. The emergence of Linux Secure Boot shouldn't affect VM creation and use, but it's still worth checking that a particular Linux distribution is signed for Linux Secure Boot.
Requirements fall into three categories: business, user and software. See examples of each one, as well as what constitutes functional and ...
Continue Reading
Application load balancers and API gateways both manage network traffic. Learn the differences between them and how to use them together in a modern ...
Continue Reading
Learn how load balancing in the cloud differs from a traditional network traffic distribution, and explore services from AWS, Google and Microsoft.
Continue Reading
