Debian 9 defers UEFI Secure Boot support

From the latest “Bits from the Release Team” message, it appears that Debian 9 will probably defer Secure Boot support to later.

Secure Boot
At a recent team meeting, we decided that support for Secure Boot in the forthcoming Debian 9 “stretch” would no longer be a blocker to release. The likely, although not certain outcome is that stretch will not have Secure Boot support. We appreciate that this will be a disappointment to many users and developers. However, we need to balance that with the limited time available for the volunteer teams working on this feature, and the risk of bugs being introduced through rushed development. It’s possible that Secure Boot support could be introduced at some point in stretch’s lifetime.

Full message:

Debian signed Shim

Secure Boot chain-loading bootloader (Microsoft-signed binary)

This package provides a minimalist boot loader which allows verifying signatures of other UEFI binaries against either the Secure Boot DB/DBX or against a built-in signature database. Its purpose is to allow a small, infrequently-changing binary to be signed by the UEFI CA, while allowing an OS distributor to revision their main bootloader independently of the CA. This package contains the version of the bootloader binary signed by the Microsoft UEFI CA.

Linux Foundation workstation security ebook

[…]Now, before you even start with your operating system installation, there are a few things you should consider to ensure your pre-boot environment is up to snuff. You will want to make sure:
* UEFI boot mode is used (not legacy BIOS) (ESSENTIAL)
* A password is required to enter UEFI configuration (ESSENTIAL)
* SecureBoot is enabled (ESSENTIAL)
* A UEFI-level password is required to boot the system (NICE-to-HAVE)

Sounds interesting, but I don’t see any actual download link for this ebook. I guess I need some sleep.

There is also this:


Microsoft updates Secure Boot and ACPI requirements

These Microsoft pages have recently (last month) been updated. No changelog, so unclear what has changed. 😦



I missed this blog post from SuSE from last year:

[…]One UEFI topic that I noticeably did not address in this blog is secure boot. This was actually covered extensively in three previous blogs. To read those blogs do a search for “Secure Boot” at I also did not address the comparison of UEFI and BIOS from the operating systems perspective in this blog. That is a separate blog that was released at the same time as this one (Comparison of UEFI and BIOS – from an operating system perspective). Please read it too. Hopefully this gives you some helpful information about the transition from BIOS to UEFI, on the hardware side. You can find more information about SUSE YES Certification at or search for YES CERTIFIED hardware at You can also review previous YES Certification blogs at YES Certification blog post[…]

FWTS 16.12.00 released

Ivan Hu of announced the release of FirmWare Test Suite release 16.12.00, with new features in UEFI Secure Boot, OpenPOWER Opal, and ACPI tests. See the full announcement for the list of bugfixes.

New Features:
* ACPICA: Update to version 20161117
* klog.json: Add a few more kernel errors to the database
* opal: pci_info: Add OPAL PCI Info validation
* opal: mem_info: Add OPAL MEM Info validation
* opal: cpu_info: Add OPAL CPU Info validation
* securebootcert: add variable AuditMode checking
* securebootcert: add variable DeployedMode checking

33rd CCC

The 33rd Chaos Communication Congress (CCC) takes place in December in Germany. There are MANY great presentations, and CCC is great at making video archives available. Here’s a sample of a few of the presentations, starting with Trammell’s lecture on Heads:

Bootstraping a slightly more secure laptop
Trammell Hudson

What could possibly go wrong with <insert x86 instruction here>?: Side effects include side-channel attacks and bypassing kernel ASLR
Clémentine Maurice and Moritz Lipp

Untrusting the CPU: A proposal for secure computing in an age where we cannot trust our CPUs anymore

Virtual Secure Boot: Secure Boot support in qemu, kvm and ovmf
Gerd Hoffmann

Full schedule:

Run As Radio: UEFI Secure Boot

Episode 503 is on UEFI and Secure Boot:

“The BIOS has evolved, and we need to take advantage of it! While at Ignite in Atlanta, Richard sat down with Mark Minasi to talk about UEFI and SecureBoot. The conversation starts out with a bit of a history lesson about BIOS, ROM and booting up a computer. Mark tells the story of how EFI started with Intel’s Itanium, and eventually appeared everywhere. UEFI is effectively an operating system in its own right, with drivers and it’s own set of security risks. This leads to a conversation around SecureBoot, dealing with the challenges of resisting security exploits from startup onward. It’s easy enough to get SecureBoot running, it’s what happens when it’s triggered that gets complicated. “


Secure Boot in vSphere 6.5

Tom Fenton has an article in Virtualization Review on the latest version of VMWare’s vSphere 6.5, and this release includes UEFI changes:

[…]Another major security upgrade in this release is “Secure Boot,” to prevent unauthorized operating systems and software from loading during the startup process. Secure Boot is a feature enabled by UEFI, and can be used not only when booting the hypervisor, but also when booting up the guests. VMware has also updated its logging to include the ability to track who did what on a vSphere system. […]

Peter Jones on Secure Boot failures and mitigations

I just now came across a blog post written by Peter Jones from LAST MONTH on that “Microsoft Secure Boot Golden Key” news reports that is worth reading. Peter owns the Linux shim, so he knows a bit about UEFI’s boot process.

Especially because I’ve had nearly nothing useful in this blog on this post:

Also note other articles in Peter’s blog: he makes regular canary posts about the state of his Shim code. I wish all of the boot/firmware code required all contributes to have canaries!

UEFI Forum updates Secure Boot revocation database?

I wish I knew some more authoritative sources of news for this Microsoft Secure Boot story… 😦 The below post implies that the UEFI Forum’s Secure Boot recovation list file has been updated in response to recent news.

I REALLY wish the UEFI Forum would *announce* when they update their Secure Boot revocation list, and include version history to the changes, and keep older releases available for diffing against current one. It seems something this important should not be under public version control so you can see when keys come and go, and why. The current web page on this database should include information about the entries in the current database, and show changes and why. The page for this database should include end-user information for sysadmins to apply this to their systems, I see no real documentation on this page on how to properly use this database.

excerpt from

[…] In response, UEFI is distributing an updated version of the Secure Boot revocation list, aka dbx. dbx is used to remove previously granted access from a UEFI driver or application, or from a signing certificate, declaring that signature invalid or signatures with the blacklisted certificate to be invalid. This update adds 64 new new individual signature entries into dbx, raising the total to 77.  […]

more on Microsoft UEFI Secure Boot golden key news

There are a few news stories coming out saying that the recent Microsoft Secure Boot stories are mostly false, pointing to a Steve Gibson video podcast.

If someone had some good technical background on this story, please leave a Comment to this post, thanks!

Kurt Mackie has a story in Redmond Magazine about the recent Microsoft Secure Boot news:

[…] There were no actual software keys involved when anonymous researchers claimed that Microsoft had leaked so-called “golden keys” to the Windows secure boot protection scheme, according to an industry veteran. That point of view was offered by Steve Gibson, president and founder of Gibson Research Corp., a small software development firm in Laguna Hills, Calif. “It was completely wrongly reported” by the press, Gibson said in a “Security Now” show yesterday. Gibson is cohost on the show, which is published by the Twit network. “It was nice work,” Gibson said about the researchers’ findings, “but the whole golden key was an absolute red herring referring to the notion of backdoor systems. But this wasn’t that. It was a mistake.” […] “What this actually was was an implementation design error in the handling of boot permission policies which can be used to trick older versions of the UEFI secure boot manager using some components of an update. So the so-called ‘Redstone’ version of Windows 10, which is version 1607, we know it as the ‘anniversary update,’ it added some new technology in the concept of supplemental secure boot policies, which can, for example, be used for test-signing development code. And of course, that could also be [used for running] malicious rootkits and so on.” […]

Kareem Anderson of WinBeta has a similar story:

Microsoft’s ‘Golden key’ is more agenda than actuality “None of that is true. Complete misreporting.”

ThinkPwn updated

Microsoft UEFI Secure Boot key problem

Chris Williams has a story in The Register about some problems that Microsoft is having with UEFI Secure Boot:
Bungling Microsoft singlehandedly proves that golden backdoor keys are a terrible idea
Redmond races to revoke Secure Boot policy

Updated Microsoft leaked the golden keys that unlock Windows-powered tablets, phones and other devices sealed by Secure Boot – and is now scrambling to undo the blunder.

These skeleton keys can be used to install non-Redmond operating systems on locked-down computers. In other words, on devices that do not allow you to disable Secure Boot even if you have administrator rights – such as ARM-based Windows RT tablets – it is now possible to sidestep this block and run, say, GNU/Linux or Android. […]

Secure Boot and driver signing changes in latest Windows 10

Joshua Baxter of Microsoft posted a new article in the Windows hardware certification blog, about changes in Win10 driver signing:

Driver Signing changes in Windows 10, version 1607
Last year, we announced that beginning with the release of Windows 10, all new Windows 10 kernel mode drivers must be submitted to the Windows Hardware Developer Center Dashboard portal (Dev Portal) to be digitally signed by Microsoft. However, due to technical and ecosystem readiness issues, this was not enforced by Windows Code Integrity and remained only a policy statement. Starting with new installations of Windows 10, version 1607, the previously defined driver signing rules will be enforced by the Operating System, and Windows 10, version 1607 will not load any new kernel mode drivers which are not signed by the Dev Portal. OS signing enforcement is only for new OS installations; systems upgraded from an earlier OS to Windows 10, version 1607 will not be affected by this change. We’re making these changes to help make Windows more secure. These changes limit the risk of an end-user system being compromised by malicious driver software. […]

More info, including a FAQ on how Secure Boot impacts this:

exploiting Lenovo firmware, part 2D

A bit more on this:

Lenovo has updated their support document. The initial version had no technical details. The update now has a huge list of models which are affected or not. The researcher also mentions that an update from the vendor is expected next month. I’m still waiting to see the IBV’s and other OEMs responses to this.


exploiting Lenovo firmware, part 2C

A bit more on this:

exploiting Lenovo firmware, part 2B

more on this:

Lenovo has a response:

System Management Mode (SMM) BIOS Vulnerability
Lenovo Security Advisory:  LEN-8324
Potential Impact:  Execution of code in SMM by an attacker with local administrative access
Severity:  High
Scope of Impact: Industry-wide

The researcher also has a few responses: