Oracle Solaris 11.4: UEFI Secure Boot on Intel HW

UEFI Secure Boot on Oracle Solaris x86 enables you to install and boot Oracle Solaris on platforms where UEFI Secure Boot is enabled. This feature provides more security by maintaining a chain of trust during boot: digital signatures of the firmware and software are verified before executing the next stage. No break occurs in the chain because of unsigned, corrupt, or rogue firmware or software during the boot process. This feature helps assure that the firmware and software used to boot Oracle Solaris on a hardware platform is correct, and has not been modified or corrupted.



DBXtool has support for Microsoft dbxupdate.bin

DBXtool[1] is a tool by Peter Jones of Red Hat. So it works with Fedora, and perhaps other versions of Linux. It is an interesting tool in that it is one of the few tools that look at the UEFI SecureBoot PKI list of blacklisted keys,  that UEFI Forum occassionally updates[2]. Last year there was the Microsoft leaks Golden Keys” story, which was overblown, watch Jeremiah’s video on Youtube from the Fall 2016 UEFI Plugfest for more details. I just noticed that DBXtool has support[3] for a dbxupdate.bin file from Microsoft, separate from the DBX file, related to this Microsoft Golden Keys incident.

Peter’s comment from that checkin:

Add a new dbxupdate.bin
This is the dbxupdate.bin referenced in CVE-2016-3320 and
It’s for their bootloaders, not ours.

WordPress mangles Github Gist URLs, so remove the spaces from the next URL to make it work:
https://gist.   df34b5213f1e0fae6529eb703d947187

Some more background on UEFI SB DBX: (English translation above Russian document)

Besides Peter’s DBXtool, I’m not aware of many other tools that use the DBX file. There’s this PowerShell script:
Again, WordPress mangles Gist URLs, remove spaces to make this work:
https://gist. 991a0bea355ec1dc19402cef1b0e3b6f

I wish I could point to a tool avaialble in each OS/distro that your firmware has the latest blacklist applied…

PS: Peter also works on the Shim. And he’s updated his canary:

proposal: add Security Version to Linux Shim

Gary Ching-Pang Lin of SuSE has submitted a proposal for Linux kernel and Shim to include a Security Version. In addition to below shim wiki page, there is active discussion on this on the Linux-EFI list.

Security Version

When a vulnerability is found, every distro will release the patch as soon as possible and push it into the update channel. However, since the signature of the old kernel is still valid, the attacker may trick the user to boot the old and insecure kernel to exploit the system. For the system with UEFI Secure Boot, although the admin can add the hashes of the insecure kernels into MokX, it could be burdensome to do this in large scale. Besides, it’s almost impossible to obsolete the kernels before a certain version. Not to mention that the old kernel sometimes might be useful for debugging. To keep the system secure and also flexible, we propose “Security Version”. The basic concept of Security Version is to use a whitelist to record the “version” of the latest known secure linux kernel. If the “version” of the kernel is lower than that in the whitelist, then the kernel is considered as “not secure”. The “version” in the whitelist can only be incremented monotonically unless the user decides to lower it.[…]

PS:  Hmm, Gmane’s linux-efi links aren’t working for me.

Matthew on improving UEFI Secure Boot on Linux with TPMs

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.

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!

GRUB with Trusted Boot for TPM v1 or v2

This from September, I only just noticed it. 😦

Matthew Garrett has updated GRUB bootloader with support for Trusted Boot, on TPM v1 or v2 systems!

In a follow-up to the above tweet, Matthew also states:

“I need to add equivalent code to Shim now lucky me”


So I need to check if that happened, and if Debian and other distros are using this version of GRUB and Shim…

I wish somebody — Wikipedia, the Linux Foundation, the Linux kernel security wiki, the UEFI Forum, etc. —  were tracking the various hardware/firmware security features of various vendors, and what system components (grub and shim in this case) had support for the various technologies, with a table of red/green boxes. Then we could more easily see things like tboot only supporting BIOS and not UEFI, etc..

TPM updates for Linux Shim and GRUB

Matthew Garrett has updated the Linux UEFI Shim and GRUB to support, based on some Trusted Grub patchset. He’s written a blog post with useful details on this update.

More information: