grub-bgrt theme: GRUB2 theme which uses UEFI logo (aka BGRT)

grub-bgrt theme: A theme for GRUB2 which uses your system’s UEFI logo (aka BGRT).

I expect this will be popular.

This old blog post is still a commonly-accessed blog post, it seems people like to hack BGRT images on their sysetms:

OEMs, consider making this a user feature via your boot menu.


Image offset value relative to display


swissarmy-grubefipxe – A configuration for netbooting various linux distros using PXE/EFI/GRUB

This is a little side-project of mine to be able to netboot various Operating Systems using EFI based computers and GRUB over PXE. I have this running on my QNAP NAS, but I believe almost any decent NAS has the requirements to run this. This project was born out of my disdain for flashing distros to USB keys.[…]

Matthew on improving UEFI Secure Boot on Linux with TPMs

Grub UEFI Settings Entry Adder

Grub UEFI Settings Entry Adder

The following repository adds a grub bootloader entry to boot into your UEFI/BIOS firmware settings. The underlying grub entry script (uefi-firmware) is a trimmed down version of this[1] script distributed by The conditions have been removed as they no longer apply to recent linux versions. It shall be noted that I have NOT replaced the conditions, but rather removed them, hence I should remind you that the grub entry may not function on every device, depending on it’s linux setup, version and the hardware.


Xen 4.9 multiboot2 support increased

At least one UEFI change in this release:

Boot Xen on EFI platforms using GRUB2 (x86):
From Xen Project 4.9 and GRUB2 2.02 onwards, the Xen Project Hypervisor can be booted using the multiboot2 protocol on legacy BIOS and EFI x86 platforms. Partial support for the multiboot2 protocol was also introduced into network boot firmware (iPXE). This makes the Xen Project boot process much more flexible. Boot configurations can be changed directly from within a bootloader (without having to use text editors) and boot configurations are more portable across different platforms.


EFI variable support for U-Boot

Rob Clark has an RFC patch to U-Boot, with UEFI variable support:

[RFC] efi: variable support

Mapping from EFI variables to grub variables. Still almost as many TODOs as lines of code, but just figured I’d send out an early version for comments. I was thinking of it as a useful way for u-boot to pass values to grub (although grub is still missing a way for grub scripts to retrieve UEFI variables). The rough idea is to encode GUID + variable name plus “efi_” prefix (to avoid unintended u-boot variables leaking into the UEFI world). And then encode the type (and attributes?) in the string value of the variable. Ie. something like:

setenv efi_8be4df6193ca11d2aa0d00e098032b8c_OsIndicationsSupported (u64)0

Full patch/thread:


Red Hat Satellite GRUB UEFI PXE script

Satellite 6 TFTP boot file legacy grub conversion script

This script is used to convert the tftp boot files (found in /var/lib/tftpboot/pxelinux.cfg/) which are automatically generated by Satellite 6 into the old legacy grub format. Why is this useful? Recently I encountered some HP servers which have an additional 10GbE card in one of the PCI-E slots on the machine which is used for the PXE boot. Unfortunately this additional interface only supports UEFI boot and not classic bios boot. By default Satellite 6 uses the shim image for UEFI but this doesn’t work with the older Linux kernel used by RHEL6.X. If this script is executed on a capsule or satellite server which has TFTP enabled, it will automatically replace the boot files using the old format which gives a successful boot for RHEL6.


GRUB 2.02 in the works…

See the FOSDEM slides for some of the features listed in the Phoronix article.

Click to access slides.pdf

Alexander on U-Boot+UEFI+GRUB on ARM

Here’s one interesting presentation for the upcoming OpenIoT and Embedded Linux Conference:

Marrying U-Boot, uEFI and grub2 – Alexander Graf, SUSE

Booting is hard. Booting in the ARM world is even harder. State of the art are a dozen different boot loaders that may or may not deserve that name. Each gets configured differently and each has its own pros and cons. As a distribution this is a nightmare. Configuring each and every one of them complicates code that really should be very simple. To solve the problem, we can just add another layer of abstraction (grub2) on top of another layer of abstraction (uEFI) on top of another layer of abstraction (u-boot). Follow me on a journey on how all those layers can make life easier for the distribution and how much fun uEFI really is. After this talk, you will know how ARM systems boot, what uEFI really means, how uEFI binaries interact with firmware and how this enables convergence of the Enterprise and Embedded markets.

Alexander Graf, KVM Wizard, SUSE
Alexander started working for SUSE about 8 years ago. Since then he worked on fancy things like SUSE Studio, QEMU, KVM and openSUSE on ARM. Whenever something really useful comes to his mind, he tends to implement it. Among others he did Mac OS X virtualization using KVM, nested SVM, KVM on PowerPC and a lot of work in QEMU for openSUSE on ARM. He is the upstream maintainer of KVM for PowerPC, QEMU for PowerPC and QEMU for S390x.


PVS-Studio blog on bugs in GRUB

What’s Hiding Inside the GNU Boot Loader? Searching for Bugs in Grub
PVS-Studio analyzer continues to explore and adapt to the Linux platform. Today we will take a look at the bugs that the tool managed to find in the Grub boot loader. In this article, we will talk about the results of analysis of the boot loader for Unix-like operating systems, known as Grub. This program was developed by Erich Boleyn and comes as part of the GNU Project. GRUB is a reference boot loader implementation compliant with the Multiboot specification and is able to boot any compliant operating system. The Grub project is written in C and has been already checked by other analyzers, including Coverity, so you wouldn’t expect to find any unchecked code fragments in a project like that. PVS-Studio analyzer, however, did manage to catch a few interesting bugs. […]


Interesting new project. I wish most modern Linux distros let you control keys in ways like this. Check out the entire web page on Github, nice read for Linux/UEFI even if you don’t plan on using cryptboot.

Encrypted boot partition manager with UEFI Secure Boot support

With encrypted boot partition, nobody can see or modify your kernel image or initramfs. GRUB boot loader supports booting from encrypted boot partition, but you would be still vulnerable to Evil Maid attacks. One possible solution is to use UEFI Secure Boot. Get rid of preloaded Secure Boot keys (you really don’t want to trust Microsoft and OEM), enroll your own Secure Boot keys and sign GRUB boot loader with your keys. Evil maid would be unable to boot modified boot loader (not signed by your keys) and whole attack is prevented. cryptboot simply makes this easy and manageable.

* Linux (x86_64)
* UEFI firmware with enabled Secure Boot
* separate /boot partition encrypted with LUKS
* cryptsetup
* openssl
* efitools
* sbsigntools
* efibootmgr
* grub (grub-efi on Debian based distributions)


And this article points out something else crazy: “but current TrustedGRUB2 doesn’t even support UEFI yet.

Enterprise: a UEFI boot loader for Linux

‘Enterprise’ is the name of a UEFI boot loader that is meant to boot 1 or more Linux ISOs off a USB thumbdrive. The last release was back in 2015, but there is recent Github code activity. SevenBits created ‘Enterprise’, in addition to ‘Mac Linux USB Loader’, which sets up a bootable USB with Enterprise.

Enterprise (named after the Starship Enterprise from Star Trek) is an EFI program that is designed to assist in booting Linux distributions from USB sticks on UEFI-based PCs and Macs, something that is continously regarded as being near to impossible due to quirks in vendors’ EFI implementations and really quite poor support from Linux distributions.  Using Enterprise, you can create bootable USB drives that boot on a UEFI-based computer without needing rEFIt or rEFInd to be installed.  Originally designed to compliment ‘Mac Linux USB Loader’, Enterprise can also be used on its own to boot Linux on a variety of UEFI-based PCs and Macs.  The purpose of Enterprise is as the first stage in a two-stage booting process for ‘Mac Linux USB Loader’-created USB drives. Enterprise is a custom UEFI boot manager designed to load Linux distributions, even those without UEFI booting support, directly from ISO files on UEFI-based computers.  Enterprise provides an easy-to-use and simplistic interface that automates many of the tasks necessary to boot distributions of Linux from an ISO file.  Enterprise supports booting multiple distributions, so you can have more than one distribution per USB stick and multiple configurations for each distribution. Enterprise requires a configuration file telling it about which distributions it should load. This configuration file is created automatically when you use tools like Mac Linux USB Loader, though it is possible to write your own file and configure Enterprise as one would configure other boot managers such as GRUB, gummiboot, and syslinux, albeit much more simply.  Enterprise is under the LGPL; it pulls in code from other software projects (namely, gummiboot). It is written in portable C, and can be compiled to run on both 32-bit and 64-bit EFI firmware types.

LUV/BITS/CHIPSEC ported from x64 to x86!!

Get ready to test your Intel x86 systems!

Megha Dey of Intel submitted an 8-part patch to LUV that enables it to build on x86.

LUV has been useful for 64-bit x64 systems, and now is getting useful for 32-bit x86 systems!

Including 32-bit versions of BITS and CHIPSEC!

Is this the first time that pre-compiled binaries of CHIPSEC for x86 systems have been available? Not sure. Anyway, if you build from source you can start now, otherwise, look for the LUV-live binary download site to start having 32- and 64-bit versions, hopefully

Excerpt from part 0 of the patch:

[PATCH 0/8] Build and run LUV on 32 bit platforms

Currently LUV can be built only for 64 bit target platforms. This patchset contains patches which make sure that LUV can be compiled and run on both 32 as well as 64 bit target platforms. This required reworking of the PE header checks, adding call wrappers used by the shim bootloader to store and restore context, making sure chainloader.c compiled for 32 bit systems, adding support to ensure correct direct directory structure for 32 bit case and removing bugs in chipsec so that it could build without any erros on 32 bit systems. Also, the bits recipe is updated to build the grub EFI image only for target builds.This patchset addresses the following issue:

grub: chainloader: shim: rework PE header checks
grub: shim: Add call wrappers for 32 bit systems
grub: shim: compile chainloader.c for 32bit system
luv : Correct directory structure for 32 bit case
luv: Add the ARCH parameter to chipsec Makefile
luv: chipsec : compile for 32 bit systems
bits: only build grub EFI image for target builds
bits: grub: specify location of images and modules for mkimage

More information:


For GRUB 0.x, there is the Trusted GRUB, from TrouSerS and the GRUB Legacy project:

I may have missed it, but I don’t think the recent GRUB Legacy project has Trusted GRUB ‘s TPM support. I hope they pick it up, it would be nice to have a single GRUB Legacy with latest UEFI and TPM support. I wonder what other forks of GRUB 0.x are worth watching?

For GRUB2, I missed this activity from Matthew back in September, but it appears that he’s added TPM support to GRUB2:

The above blog post mentions Sirrix AG’s TrustedGRUB, that it was based on.

I just noticed that the TrustedGRUB2 project from Sirrix AG has also been recently updated:

Hmm, there’s some UEFI 2.5-centric checks in the Sirrix tree, too:

So it appears that both Matthew’s GRUB2 as well as Sirrix’s current TrustedGRUB2 are both of interest, probably others (how many others??).  Why doesn’t upstream GRUB2 take all these patches, anyway? Is it an FSF issue with TPM/UEFI-centric code? I wish UEFI Form was a bit more proactive with GRUB[2], two of the most influential UEFI ‘pre-OS’ applications in use.


New UEFI-patched GRUB Legacy

There’s a new GRUB Legacy build on Github, which has some UEFI patches, called grub0.97-patched. The forker has a strong opinion towards GRUB 2… 🙂


“A fork of GRUB 0.97 (aka Legacy), included several patches for UEFI, RAID, GPT, … I created this repo to archive the last version of GRUB Legacy and their community-made patches that were scattered all over the Internet. GRUB development team has deleted the repo of GRUB Legacy, citing that GRUB 2 is the future. In fact, their future is shit.”


Grub2 exploitable

Warning, GRUB2 has some input issues:

Authors:    Hector Marco & Ismael Ripoll  —  Cybersecurity Group
CVE:    CVE-2015-8370
Comment:    Grub2 Authentication Bypass 0-Day
Dates:     December 10th, 2015 – Disclosed at IX Jornadas STIC CCN-CERT.
December 14th, 2015 – Published in the web.

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