Just recently, I found myself forced to disable Secure Boot in the BIOS on my Lenovo X1 Extreme to update NVMe firmware drivers. That’s reported in the May 14 Win10.Guru post Lenovo NVMe Firmware Update Finally Fixed. This experience made me more curious about Secure Boot, especially as it can impact various kinds of capablities and installations on Windows 10 PCs. In this blog post, I’ll summarize my findings and include a few “war stories,” including an interesting — and ongoing — one from Kari.
Just the Basics: What Is Secure Boot, Anyway?
Good question. Let me start this exploration and explanation with some information from the introduction to the UEFI Forum’s September 2013 document UEFI Secure Boot in Modern Security Solutions (PDF format):
UEFI Secure Boot was created to enhance security in the pre-boot environment. UEFI Forum members developed the UEFI specification, an interface framework that affords firmware, operating system and hardware providers a defense against potential malware attacks. Without UEFI Secure Boot, malware developers can more easily take advantage of several pre-boot attack points, including the system-embedded firmware itself, as well as the interval between the firmware initiation and the loading of the operating system. Malware inserted at this point can provide an environment in which an operating system—no matter how secure—cannot run safely.
Microsoft’s Hardware Dev Center article (part of MS Docs) on Secure Boot explains further that this technology is intended to
help make sure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM). When the PC starts, the firmware checks the signature of each piece of boot software, including UEFI firmware drivers …, EFI applications, and the operating system. If the signatures are valid, the PC boots, and the firmware gives control to the operating system.
Two Important Points Regarding UEFI Secure Boot
This leads me to stress two important points where UEFI Secure Boot is concerned (or, perhaps more appropriately, where it could come into play):
First, UEFI Secure Boot only applies to systems that use the Extensible Firmware Environment (EFI) to boot. For Windows 10 systems, these will have a disk layout that includes an EFI partition, like this one from the Lenovo X1 Extreme (I outlined the EFI partition in red to make it instantly identifiable; it does not appear that way in Disk Management normally):
The EFI partition is labeled as such in the built-in Disk Management facility. Though it shows up as empty therein, it actually contains various and numerous boot-related files.
[Click image for full-sized view.]
In fact, if you use a tool like MiniTool Partition Wizard (MTPW), you can explore EFI partitions to see what’s inside them. Here’s a snapshot of my production PC’s EFI partition from that tool’s Partition Explorer facility that shows a (mostly) folder-level view of its contents:
Despite its scant contents, the EFI partition is NOT empty, as this view from MTPW’s Partition Explorer shows.
Older Windows systems may not support UEFI. These will only support what’s now called “Legacy Boot,” which typically uses a Master Boot Record (MBR) style system disk layout instead. The easiest ways to tell if EFI boot is used are to (a) check the BIOS to see if it includes or mentions UEFI or Secure Boot, or (b) to inspect the system/boot disk layout to look for the presence or absence of an EFI partition. If one is present, UEFI boot is in effect; if one is absent, UEFI boot is not in use (though the system may still support UEFI anyway, it is not currently using that technology).
Second, you can check any Windows 10 installation to examine its Secure Boot state. If you run the built-in Windows 10 System Information utility, it includes a System Summary item named “Secure Boot State.” This will show as either “On” or “Off” to reflect the running OSes Secure Boot status. Here’s what that looks like on the Lenovo X1 Extreme (red arrow at left points to relevant item):
This output from System Information shows that I turned Secure Boot back on after turning it off to install the NVMe Firmware drivers.
[Click image for full-sized view.]
When Can Secure Boot Get in the Way, or Cause Problems?
In general, Secure Boot will be enabled by default on systems that come with Windows 10 already installed. That’s because maintaining boot-level security, as this facility is intended to do, is generally a good thing. But there may be certain occasions when this typical default may stymie or interfere with Windows or other installations. Thus, for example, we already know that in some circumstances, a firmware update may not work unless Secure Boot is disabled when that update is applied (as was the case on the X1 Carbon and the Samsung NVMe firmware update for its pair of NVMe drives). There are other cases where Secure Boot can interfere with certain operations. I will recite them in the subsections that follow.
Kari’s Story: Secure Boot Negates Boot to VHD
Here’s what Kari says about his HP ProBook laptop:
Disk1 is a small 128 GB SSD, and Disk0 a 1TB HDD. The SSD only contains UEFI system partitions, and the Windows partition C:. Disk0 contains partitions for software, users and Hyper-V.
My OS is EN-GB W10 PRO. I install other editions and language versions in Hyper-V VMs, or quite often as native boot VHD(s), adding it / them to the Windows boot menu.
When Secure Boot is enabled, the laptop and Windows on the SSD work perfectly. But each attempt to boot to a VHD causes the Recovery screen to appear. With Secure Boot enabled, it won’t boot to a VHD. I must boot into the UEFI settings, disable Secure Boot, and only then am I able to boot into any of my VHDs.
This is a case where Kari is more inclined than not to leave Secure Boot disabled on his HP laptop, because he frequently boots from one of the VHDs on that PC.
TenForums Tutorial 1: Enable/Disable Secure Boot
There’s are at least two excellent tutorials on Secure Boot at TenForums.com. One is entitled “How to Enable or Disable Secure Boot on Windows 10 PC.” Its introduction includes the following observations, worth reading and heeding (I have bolded some of the text quoted for emphasis):
Sometimes you may need to disable Secure Boot to run some PC graphics cards, hardware, or operating systems such as Linux or previous version[s] of Windows. Before disabling Secure Boot, consider whether it is necessary. From time to time, your manufacturer may update the list of trusted hardware, drivers, and operating systems for your PC. To check for updates, go to Windows Update, or check your manufacturer’s website.
The other TenForums.com tutorial is entitled “Check if Secure Boot Is Enabled or Disabled in Windows 10.” In addition to the System Information check I mentioned earlier in this post, it also points to other methods for checking that include the PowerShell Confirm-SecureBootUEFI cmdlet. Interestingly, this cmdlet reports “True” for UEFI systems with Secure Boot enabled, “False” for such systems with it disabled, and “variable . . . undefined” for non-UEFI systems.
User comments in both tutorials are interesting and informative. We learn from those comments on the second tutorial, for example, that “different manufacturers have different criteria and/or “lists” of what they think is “secure” — by which I believe the poster means differing evaluations for firmware elements that meet or fail signature matching or other requirements for inclusion into what’s allowed (and not allowed) during the pre-boot phase. This is when EFI changes, and BIOS and firmware updates, typically occur. In comments on the first tutorial we learn that dual boot scenarios can be difficult or questionable with Secure Boot enabled, and that Dell, HP, and Lenovo offer differing levels of support and/or recognition for firmware updates (especially updates that originate from third parties, and not through their official release/update channels).
Formulating a Secure Boot Rule of Thumb
In general, if you try to clean install or upgrade an OS, or must install pre-boot software (EFI components or updates, BIOS updates, or firmware updates or drivers), you should be aware that Secure Boot may interfere with any or all of these activities. Thus, the rule of thumb is to try it and see what happens. If it fails, and Secure Boot is enabled, try again with Secure Boot disabled. It just may work! Then, when you’re finished — unless you’re in a situation like Kari’s where booting to a VHD doesn’t work at all when Secure Boot is enabled — don’t forget to re-enable Secure Boot to regain boot-level software protection for everyday use.
Author: Ed Tittel
Ed Tittel is a 30-plus-year computer industry veteran. He’s a Princeton and multiple University of Texas graduate who’s worked in IT since 1981 when he started his first programming job. Over the past three decades he’s also worked as a manager, technical evangelist, consultant, trainer, and an expert witness. See his professional bio for all the details.