CoreOS announces new service

Yuck, the CoreOS marketing team demands contact info before letting you read their whitepaper. But, Matthew is working there…

More info:

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..

Matthew on kernel security

Matthew Garrett has a new blog post, on the topic of the need to improve Linux kernel security. Excerpt:

The model up until now has largely been “Fix security bugs as we find them”, an approach that fails on two levels:

1) Once we find them and fix them, there’s still a window between the fixed version being available and it actually being deployed
2) The forces of good may not be the first ones to find them

This reactive approach is fine for a world where it’s possible to push out software updates without having to perform extensive testing first, a world where the only people hunting for interesting kernel vulnerabilities are nice people. This isn’t that world, and this approach isn’t fine.

Full article:

VZ on Secure Boot, Intel TXT, Linux, and UEFI

Earlier today, Matthew Garret posted a problem on Twitter about Intel Linux and Intel TXT mode:

Later that day, Vincent Zimmer of Intel is apparently helping to get that Intel project working with UEFI:

A few weeks ago, a similar thing happened with Intel SGX. Intel is lucky to have Vincent Zimmer, who is very engaged with Linux security/development community, in helping to fix Intel projects to properly support UEFI. Many large companies do not have this kind of public individual involvement.

MJG on Secure Boot, Intel TXT, Linux, and security

A short security lesson from Matthew (click on Twitter link for follow-up post):

[BTW, sorry WordPress doesn’t seem to render Twitter’s HTML table when scrolling through the site If you ever see multiple blank lines in the post it is probably a Twitter URL that WordPress didn’t render, refresh to fix. You have to refresh on new pages, often, or view the post on a separate page (which generates a refresh). I post messages while online and finding news, but don’t spend a huge amount of extra time formatting the posting, simple ASCII text plus a few URLs. The interactive WordPress HTML UI to add a hyperlink triples the time to post each message, and WordPress won’t accept HTML <A> links. WordPress renders some URLs differently, like showing the image of a JPEG/PNG/etc, and showing the Youtube video link and hiding the rest of a web page which contains a Youtube URL — like Kickstart funding pages.]

Clarification of Matthew Garrett’s Linux fork

Some irresponsible bloggers have been commenting about Matthew’s fork of Linux:

ZDNet has a story with comments from Matthew explaining things:

“I wouldn’t say I’m forking. I’d say that I’m doing my own development work away from LKML. Right now it’s got the securelevel work in it because that’s the only code I have that I feel is ready for public use, but it’ll pick up other bits of code that I’m working on as they become mature.”

I guess I look at Matthew’s fork is like the GRSecurity patch for Linux kernel: Matthew’s got the patchset that enables UEFI Secure Boot to be secure on Linux. I hope Tails, Qubes, and other security-minded distros use Matthew’s kernel, at least in builds for UEFI-based systems.

[One of the causes of the above issue is Linus having to deal with Microsoft as a CA. UEFI Forum could also deal with this by putting in place a CA that is not an OSV/OEM. OEMs could be making Linux-friendly sytsems, not just Windows- or Chrome boxes, where Linux is an afterthought second install, which is a lot harder to do with UEFI/Windows Secure Boot — and even Chrome Verified Boot. Linux Foundation could also be helping, by working with OEMs.]

Matthew Garrett’s new Linux fork

Matthew Garrett posted a blog bout leaving the Linux kernel community as a volunteer.

Excerpt from that blog:

Reaction to Sarah’s post about leaving the kernel community was a mixture of terrible and touching, but it’s still one of those things that almost certainly won’t end up making any kind of significant difference. Linus has made it pretty clear that he’s fine with the way he behaves, and nobody’s going to depose him. That’s unfortunate, because earlier today I was sitting in a presentation at Linuxcon and remembering how much I love the technical side of kernel development. “Remembering” is a deliberate choice of word – it’s been increasingly difficult to remember that, because instead I remember having to deal with interminable arguments over the naming of an interface because Linus has an undying hatred of BSD securelevel, or having my name forever associated with the deepthroating of Microsoft because Linus couldn’t be bothered asking questions about the reasoning behind a design before trashing it.

He also notes that “I’m doing a kernel. It won’t be big and professional like Linux.” It already has one commit:

kexec/uefi: copy secure_boot flag in boot params across kexec reboot

Kexec reboot in case secure boot being enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load.  In this state, the system is missing the protections provided by secure boot. Adding a patch to fix this by retain the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot.

More Information:

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:

Intel porting KGT to UEFI

The other day I learned about Intel KGT:

Then I noticed Matthew Garrett’s twitter feed, saying that it didn’ t work with UEFI… But today I note that Vincent Zimmer of Intel has a new Twitter post,  saying that Intel is working on porting KGT to work with UEFI:

Looking forward to UEFI-enabled iKGT!

dEFIant: new UEFI game engine

Nate Brune, a 16-year old high school student, just released:

dEFIant: The best UEFI game engine on the market!
The only ring0 game engine on the market

There are a few other UEFI games, but there are so few that I doubt “best UEFI game engine” cannot be argued with, yet. 🙂 I like the name, reminds me of “rEFIt” and “rEFInd”.

Back in 2013, Matthew Garrett ported Zork’s Z-Machine to UEFI:

Also back in 2013, there’s a Tetris implementation for UEFI:

There’re 1-3 other UEFI games on Github, sorry no better pointers but here:

Somewhere I think I still have patches for GNU Go and BSD Fortune ports, from when I was learning to use the EADK. 😦 I’m waiting for someone to port MAME to UEFI, only then will UEFI be “the new DOS”. 🙂

Matthew Garrett hardware talk at OSCON

As reported on by Seth on the Cypherpunks list, Matthew Garrett of CoreOS gave a talk earlier today at OSCON, on open hardware design, with a security background. OSCON is The O’Reilly Open Source Convention, probably the largest open source convention in North America. The slides are online, no audio/video yet, AFAICT. (I hope OSCON doesn’t continue to charge for access to post-conference video…)


Building a trustworthy computer
Matthew Garrett (CoreOS)
11:10am–11:50am Friday, 07/24/2015

The Snowden revelations demonstrated the lengths that government agencies  
were willing and able to go to in order to subvert computers. But these  
attacks aren’t limited to state-level actors – security researchers  
continue to demonstrate new vulnerabilities and weaknesses that would  
permit sophisticated criminals to achieve the same goals.

In the face of these advanced attacks, what can we do to detect and  
mitigate them? How can we make use of existing security features, and what  
changes can we make to system design? In short, how can we ensure that a  
user can trust that their computer is acting in their interests rather  
than somebody else’s?

This presentation will cover some of the existing security features and  
recent design changes in systems that can make it easier to detect  
attacks, and provide mechanisms for defending against them in the first  
place, along with simple design changes that would make it easier for  
users to ensure that components haven’t been backdoored. In addition it  
will discuss some of the remaining challenges that don’t have solid  
answers as yet. Topics covered will include: Firmware security, Trusted
platform modules, attestation, and associated privacy risks, Hardware
design to support offline verification, Remaining components that could
act against the interests of the  hardware owner

Matthew Garrett is a security developer at CoreOS, specializing in the  
areas where software starts knowing a little more about hardware than  
you’d like. He implemented much of Linux’s support for UEFI Secure Boot,  
does things with TPMs and has found more bugs in system firmware than he’s  
entirely comfortable with.

LinuxCon North America this August in Seattle

LinuxCon North America is happening this August, in Seattle for the first time (I think). A quick look at their schedule shows a variety of interesting presentations related to firmware security:

* Extending the Secure Boot Certificate and Signature Chain of Trust in the OS – Fionnuala Gunter, Hypori
* Resurrecting Internet Booting – Boot Boot, Booting Over the Internet – John Hawley, Intel
* Demystifying ACPI and EFI via Python and BITS – Josh Triplett
* ACPI for Network Switches – Dustin Byford, Cumulus Networks
* Tying TPMs Throughout The Stack – Matthew Garrett, CoreOS
* Turtles All The Way: Running Linux on Open Hardware – Rob Landley
* ACPI 6 and Linux – Rafael J. Wysocki, Intel
* The Bare-Metal Hypervisor as a Platform for Innovation – Russell Pavlicek, Citrix
* Suspend/Resume at the Speed of Light – Len Brown, Intel

Josh Triplett on BIOS BITS sounds especially interesting. It’ll be interesting to see if the boot boot reboot will get integrated with UEFI HTTP Boot support.

More information:

Comments on recent Reddit on UEFI and Linux

There’s a popular Reddit going on about UEFI and Linux:

which I noticed on Matthew Garrett’s blog, which also has some good insight on the topic:

The Reddit author is complaining to Intel and Microsoft about the bloat of UEFI compared to a minimal boot loader, and the need for Coreboot, and how Linux doesn’t need most of this bloat.

“Unfortunately this means that it’s extremely complicated and big. The firmware is now as big and complicated as a full-fledged OS.”

Actually, UEFI *is* an OS, not just a firmware/boot loader like Coreboot or BIOS. UEFI is a complex OS, with dozens of driver models. The original IBM PC had BIOS, and was useless without MS-DOS (or another OS). Modern UEFI-based systems have no need for BIOS, the UEFI driver models replace BIOS OptionROMs, and UEFI can be either an OS or a firmware loader, depending on how used. UEFI systems don’t need an additional OS — Windows, Linux, etc. — to be installed. The UEFI OS is about as useful as MS-DOS 2.0, a shell, about 80 commands, a handful (edit, hexedit) of full-screen ‘curses’-like. Tweaking the shell to run your embedded app, there’s no need for the bloat of an additional OS.

“Complicated and big is bad. This means more bugs. Some bugs are security bugs so more bugs means more security holes. Also it’s generally proprietary so you have different groups of people trying to write the same thing from scratch so they can inject their ‘secret sauce’. So now not only you have something that is big and buggy, but also has lots of different sets of unique bugs.”

“Also it allows for a lot of fancy new ways to manage your hardware independently of the OS. Which while often convenient it is also going to be full of bugs and is proprietary. Which is going to be especially bad when the UEFI stuff allows for remote configuration and will piggy back on your network interfaces and doesn’t go away completely when the real OS is loaded.”

Small is nice. Secure is also nice. Modern BIOS have to deal with NIST and NSA/IAD guidelines for secure BIOS, and how that drives some sales. ..which Microsoft uses well to get SecureBoot into most systems. Google has taken barebones Coreboot and made is much more complex, in the name of security, when adding SecureBoot-like PKI features in Chromium. Large servers are more complex w/r/t updating firmware, and have various ‘pre-OS’ apps (iLO, IPMI, etc.) all of which were designed for some business need (hopefully beyond merely to sell hardware), and IPMI is ripe with security issues. UEFI attempts to deal with this, I’m not sure how Coreboot deals with or ignores this reality.

UEFI is well-entrenched in the PC world, used by Apple and Microsoft and Intel, and Windows OEMs do whatever Microsoft says. I don’t see future with a non-UEFI solution for Intel-based Windows OEMs. An alternate route for Linux OS users may be to focus on Chrome OEMs, which use Coreboot. Or to focus on AMD systems, which also use Coreboot. Or to focus on ARM systems, which use either U-Boot or UEFI, the latter mostly for business reasons not technical reasons, AFAICT.

Linux OEMs could select Coreboot. Linux OEMs could build UEFI using Coreboot as it’s PI layer, reducing a bit of UEFI complexity with Coreboot. Linux OEMs could use UEFI properly, without MSFT CA or keys, using SecureBoot to secure Linux, without begging Microsoft for permission to secure non-Windows OSes on WindowsPCs — Intel and SuSE demonstrated this at IDF in 2013, yet I’ve not seen a single Linux consumer device made by OEMs for Linux users. Last time I talked to a Linux OEM, a few weeks ago, they liked UEFI, since SecureBoot scared their Linux-centric customers to legacy BIOS systems, and the OEM was too lazy to work with Sage Engineering to reduce the number of blobs in their code and add Coreboot support to their units. Linux OEMs are not that bright. Neither are Windows OEMs, but Microsoft tells them what to do, there is nobody telling Linux OEMs what to do. Where is the Linux Foundation, offering leadership in this area?