Red Hat UEFI Secure Boot patch for Linux kernel

Red Hat’s Product Security team is working with OSS-security to get a CVE listed for the below patch. Excerpting the OSS-security request from Wade Mealing of Red Hat, which was in turn paraphrased from Linn Crosetto, perhaps others:

When the kernel was booted with UEFI Secure Boot enabled, securelevel is set. If kexec (either through crash or admin action) is then used to load the same kernel, after reboot securelevel is disabled. In this state, the system is missing the protections provided by securelevel, for example kexec may be used to load an unsigned kernel via the legacy system call kexec_load. In the securelevel patchset, the state of UEFI Secure Boot is queried in the EFI stub, and sets a boot_params flag to indicate the state of UEFI Secure Boot. This flag is then used in setup_arch() to determine the correct state of securelevel. If the kernel is not booted via the EFI stub, securelevel is not set even if UEFI Secure Boot is enabled.

TLDR: this allows a bypass the security mechanism of securelevel/secureboot combination.

This patchset affects Red Hat specific kernels as secureboot is not fully fully implemented upstream yet.

It appears you need an account to view the bug database entry, and the patch:
Patch: https://bugzilla.redhat.com/show_bug.cgi?id=1243998#c3
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1243998

Clarification of Matthew Garrett’s Linux fork

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

Matthew Garrett’s new Linux fork

MJG on Linux securelevel

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

http://www.zdnet.com/article/matthew-garrett-is-not-forking-linux/

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

EFI Mixed Mode patchset for Android-IA

Christopher Price posted availability of a patchset to restore EFI Mixed Mode to the latest Android-IA release. Excerpt of announcement:

Enclosed you will find 19 patches that restore EFI Mixed Mode to the latest Android-IA release. We are still running through a BFD linker bug in KernelFlinger that is preventing activation – but it has tested well with GMIN64 and does not appear to block the kernel. Testing and review appreciated. We’d like it committed upstream because it would be very difficult without trunk access to maintain these patches going forward. While we’d like to take credit, Mark Gross and Intel UK really did an excellent job reviving this work – we’ve been incubating and testing for the past few months. This will allow Android-IA to run on the millions of BayTrail-T production tablets that depend on EFI Mixed Mode. Without these patches, Android-IA cannot run on virtually any Bay Trail tablet today, except for maybe IRDA, which isn’t available in many countries currently. These patches should no longer be necessary once Kernel 3.15 is integrated, at which point Mixed Mode will hit mainline… or at least, should hit mainline.

http://console.com.co/wp-content/uploads/mixed-mode.zip

https://lists.01.org/pipermail/android-ia/2015-October/001003.html
http://www.phoronix.com/scan.php?page=news_item&px=MTY0OTI
https://lwn.net/Articles/589193/

 

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:

http://mjg59.dreamwidth.org/38136.html
https://github.com/mjg59/linux
https://github.com/mjg59/linux/commit/4980702888a73e0fd4b48ef6f6683345011aa3a6
https://twitter.com/mjg59/
http://arstechnica.com/information-technology/2013/02/linus-torvalds-i-will-not-change-linux-to-deep-throat-microsoft/

Comment
byu/lazyindian from discussion
inlinux

http://sarah.thesharps.us/2015/10/05/closing-a-door/

Linux kernel signing history

Rebecca Shapiro has posted an article, “A History of Linux Kernel Module Signing“, introductory paragraph excerpted below:

This article was originally written back in 2014 to accompany the talk I gave at Shmoocon called “The History of Linux Kernel Module Signing”. It is a discussion of various Linux kernel module signing implementations while highlighting some of the motivating factors behind various design decisions. I decided it was about time to publish this write up, so here it is. I have not found kernel module signing implementations outside of those created by Red Hat and by the mainstream Linux developers so there may be other flavors of Linux module signing that I do not mention here. The information I present here is based on Linux developer mailing lists and source code I have found. I do not have an insider perspective of the implementation decisions. If you want the ground truth, you should go talk to those developers who are a part of the narrative I present here.

Full article:

http://www.cs.dartmouth.edu/~bx/blog/2015/10/02/a-history-of-linux-kernel-module-signing.html

Looking just at UEFI Secure Boot issues with Linux driver signing, Linux distros do vary in their strength, I wish someone would gather data about this behavior for the mainstream distros.

Secure Boot strength varies by Linux implementation

new efi_capsule_loader Linux kernel interface from Intel

Hock Leong Kweh of Intel posted a patch to the Linux kernel which exposes a new UEFI capsule update interface. Some excerpts from the patch:

efi: a misc char interface for user to update efi firmware

Introducing a kernel module to expose capsule loader interface (misc char device file note) for user to upload capsule binaries. This option exposes a loader interface “/dev/efi_capsule_loader” for user to load EFI capsule binary and update the EFI firmware through system reboot. It expose a misc char interface for user to upload the capsule binary and calling efi_capsule_update() API to pass the binary to EFI firmware. The steps to update efi firmware are:

1) cat firmware.cap > /dev/efi_capsule_loader
2) reboot

Any failed upload error message will be returned while doing “cat” through Write() function call. Tested the code with Intel Quark Galileo platform. This patchset is created on top of Matt’s patchset:
1.)https://lkml.org/lkml/2014/10/7/390 “[PATCH 1/2] efi: Move efi_status_to_err() to efi.h”
2.)https://lkml.org/lkml/2014/10/7/391 “[PATCH 2/2] efi: Capsule update support”

See the linux-kernel/linux-efi/linux-fsdevel list archives for the patch (gmane.org is down for me currently, hope it returns…):
http://dir.gmane.org/gmane.linux.kernel.efi
http://vger.kernel.org/majordomo-info.html

Kylin

Quoting Wikipedia, “Kylin is an operating system developed by academics at the National University of Defense Technology in the People’s Republic of China since 2001. It is named after the mythical beast qilin. The first versions were based on FreeBSD and were intended for use by the Chinese military and other government organizations. With version 3.0 Kylin became Linux-based, and there is a version called NeoKylin which was announced in 2010. In 2013, it was announced that a new Linux-based operating system with the same name would be released using Ubuntu. The first version, Ubuntu Kylin 13.04, was released on 25 April 2013.

QZ.com has a new review of this OS, including some screenshots:

http://qz.com/505383/a-first-look-at-the-chinese-operating-system-the-government-wants-to-replace-windows/

I still don’t know what firmware it uses. I’ve not found the source code yet. 😦

More Information:

http://www.kylinos.com.cn/
http://www.kylin-os.com/products/os/
http://www.cassc.org.cn/english/product_of_kylin.htm
https://en.wikipedia.org/wiki/Kylin_%28operating_system%29

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:

https://github.com/mjg59/shim/tree/tpm

https://github.com/mjg59/grub

http://mjg59.dreamwidth.org/37656.html

LUV 2.0 RC3 released

Ricardo Neri of Intel announced version 2.0-RC3 of the LUV (Linux UEFI Validation) distribution today. It includes fresh versions of CHIPSEC, FWTS, BITS, as well as changes to LUV. Excerpts of announcement:

This release includes improvements to allow to use the same LUV USB stick several times and save the results of all the executions. This comes handy when, for instance, you want tests several systems or you need to run LUV several times if you are debugging. From now on, the luv-results directory name will be appended with a timestamp; it will look like: luv-results-yyyy-mm-dd–hh-mm-ss. A new directory will be created each time you run LUV. If, for any reason (e.g., your system resets the real time clock each time you reboot) a directory with the same timestamps exists already in the luv-results partition, a number will be appended to the newly created directory.

We have bumped the following test suite versions: FTWS is now V15.09.00, CHIPSEC is now v1.2.1, BITS is now 2005.

On top of FWTS, we have a applied a patch to downgrade the the severity of failure in systems that are prepared for Secure Boot (i.e., have a database of keys and certificates) but do not have the Microsoft UEFI CA certificate. This is especially relevant for users that want to build their own chain of trust. This is a patch that is in process of being merged in to FWTS (https://lists.ubuntu.com/archives/fwts-devel/2015-September/006884.html).

We also have included a change in the LEG (Linaro) kernel to fix a build break due to a problem in the kernel configuration. Work is in progress to use the mainline kernel instead of the LEG kernel tree.

There are patches to improve builds of sbsigntool in native and cross-compilation mode.

More info:
https://lists.01.org/pipermail/luv/2015-September/000610.html

https://download.01.org/linux-uefi-validation/v2.0/luv-live-v2.0-rc3.tar.bz2
https://download.01.org/linux-uefi-validation/v2.0/sha256_sums.asc

Gentoo support for EDK2

On the EDK2-devel mailing list, Stéphane Veyret just announced Gentoo Linux for EDK2, including rEFInd application support. Excerpt:

I made a Gentoo ebuild for EDK2. This ebuild transforms a little bit the installation in order to be able to use the product as is generally used a library in Linux. Samples are also modified. I also made an ebuild for rEFInd as a proof of concept.

More Information:
https://github.com/sveyret/sveyret-overlay
http://permalink.gmane.org/gmane.comp.bios.edk2.devel/2446

Intel Clear Linux announces Clear Containers for Docker

Today Dimitri John Ledkov of Intel’s Linux team announced the availability of Clear Containers for Docker Engine for multiple OSes. This enables executing existing Docker applications in the secure and fast Clear Containers environment. The experimental source code is based on the Docker 1.8.1 upstream release. The primary host platform is Clear Linux Project for Intel Architecture, version 4000 or better, and binaries for multiple OSes, including: CentOS, Scientific Linux, Fedora, openSUSE, Debian, and Ubuntu.

The Clear Linux Project for Intel Architecture is a distribution built for various cloud use cases in order to showcase the best of Intel Architecture technology, from low-level kernel features to complex applications that span across the entire OS stack. We’re putting emphasis on power and performance optimizations throughout the operating system as a whole. Clear Containers leverage the isolation of virtual-machine technology along with the deployment benefits of containers. The security of containers is improved by using Intel Virtualization Technology (Intel VT). The optimization of key components results in slimmer, simpler, safer and substantially speedier virtualization.

For more information, see the full announcement on the archives of the dev list.

https://lists.clearlinux.org/mailman/listinfo/dev
http://clearlinux.org/
https://software.opensuse.org/download.html?project=home%3Aclearlinux%3Apreview&package=clear-containers-docker
https://clearlinux.org/features/clear-containers
https://lwn.net/Articles/644675/
https://github.com/clearlinux/docker

Home

Linux firmware update

As pointed out on Phoronix, there’s a new blog post by Peter Jones of Red Hat on the status of firmware updates on Linux.

http://blog.uncooperative.org/blog/2015/09/16/an-update-on-firmware-updates/

Phoronix has been covering this much better than I have:

http://www.phoronix.com/scan.php?page=search&q=ESRT

http://www.phoronix.com/scan.php?page=search&q=fwupd

http://www.phoronix.com/scan.php?page=news_item&px=Linux-UEFI-Firmware-Sept

Security focus of next Linaro Connect

Linaro Connect is happening in 4 days in San Francisco.

“The theme for the week is security.”

The security track:
* Security requirements on ARMv8-A boot architecture
* Linux kernel generic TEE driver
* OP-TEE Content Decryption with Microsoft PlayReady on ARM
* Expanding security choices: DRM & CA interoperability
* Expanding security choices panel
* Secure storage in OP-TEE
* Lessons learned on migrating open source Chromium-OPTEE to 96Boards
* TBD
* TBD

More Information:
https://www.linaro.org/news/keynote-speakers-lined-up-for-linaro-connect-sfo15/
http://connect.linaro.org/sfo15/

Rekall forensics of XEN

There’s a nice blog in the Rekall forensics blog about memory forensics of XEN systems:

If you’ve ever taken a memory image of a Linux virtual machine that’s running under XEN in paravirtualization mode and you’ve tried to analyze it you’ll have noticed most of your plugins don’t work (if any). The reason is that XEN’s page tables are funky. XEN uses a technique known as direct mapping which significantly differs from how memory management is done in many other virtualization solutions.

More Information:
http://rekall-forensic.blogspot.com/2015/08/xen-paravirtualization-support-in-rekall.html
http://www.rekall-forensic.com/
https://github.com/google/rekall

FWTS updated

Ivan Hu of Canonical has announced the release of FWTS (FirmWare TestSuite), to 5.09.00. FWTS is a set of command line tools for Ubuntu-based and related Linux systems. It also includes a curses-based interface frontend, which is also the default UI to FWTS-live. FWTS is also included in LUV, the Linux UEFI Validation distribution, but it may be a few days until this latest release has been updated in LUV-live. The release features many bugfixes, as well as some new updates/features, including:

* Update ACPICA to version 20150717
* SMBios 3.0.0 tests supported
* acpi: add _CR3 test
* acpi: add _MTL test
* acpi: add _RST test
* acpi: add _PRR test
* dmicheck: SMBIOS 3.0.0 test

For more information, see the full announcement on the fwts-announce mailling list, and see the full changelog, /usr/share/doc/fwts/changelog.Debian.gz in the source tarball.

https://launchpad.net/ubuntu/+source/fwts
http://fwts.ubuntu.com/release/fwts-V15.09.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/15.09.00

KVM Forum 2015 materials available

[[ UPDATE: WordPress mangles the below URL to Pauolo’s SMM talk. Download the PDF from the linux-kvm.org link below instead. ]]

The KVM Forum recently finished, and their post-conference materials are available, including videos of some of the presentations. There are multiple interesting talks on QEMU and KVM for security researchers. Two talks that jump out to me are:

Securing secure boot: system management mode in KVM and Tiano Core
by Paolo Bonzini

Click to access 03×06-Aspen-Paolo_Bonzini-Securing_secure_boot.pdf

Using IPMI in QEMU
by Corey Minyard

Click to access 03×08-Juniper-Corey_Minyard-UsingIPMIinQEMU.ods.pdf

More Information:
http://www.linux-kvm.org/page/KVM_Forum_2015

Secure Boot for USBArmory

[[  UPDATE: Earlier I called this “UEFI Secure Boot”. Vincent Zimmer of Intel read their blog article more closely than I did, read the comment he just made:  click on the “Comment” link on the left side of the blog, At the moment, I am not sure what flavor(s) of “Secure Boot” InversePath is using for the USB Armory. ]]

InversePath has updated the USB Armory to support Secure Boot (unclear what kind of  “Secure Boot” this is..

Interesting read to see what is involved in getting Secure Boot to work, even if you don’t have one of these devices. I like the disclaimer:

IMPORTANT: enabling Secure Boot functionality on the USB armory SoC, unlike similar features on modern PCs, is an irreversible action that permanenty fuses verification keys hashes on the device. This means that any errors in the process or loss of the signing PKI will result in a bricked device uncapable of executing unsigned code. This is a security feature, not a bug. The activation and use of the Secure Boot functionality is therefore at your own risk and must be approached with care.

https://github.com/inversepath/usbarmory/wiki/Secure-boot