GRUB 2.04-rc1 released

Quoting LinuxJournal:

“[…]GRUB 2.04-rc1 has been released. Phoronix reports that after nearly two years of development, this release will bring tons of changes, including “supporting multiple early initrd images, support for the F2FS file-system, a verifier framework, RISC-V support, UEFI Secure Boot shim support, Btrfs Zstd improvements, Btrfs RAID5/RAID6 support, Xen PVH support, UEFI TPM 1.2/2.0 support, and a lot of other work.[…]”

http://git.savannah.gnu.org/cgit/grub.git/

https://www.linuxjournal.com/content/grub-204-rc1-released-mozilla-designing-better-security-messages-back-door-discovered

https://www.phoronix.com/scan.php?page=news_item&px=GRUB-2.04-Release-Candidate

GRUB2 security changes in Fedora

[…]Include Grub’s “verify,” “cryptodisk,” “luks” and <others here> modules in grubx64.efi of the ‘grub2-efi-x64’ package.  Users utilising secure boot functionality on the UEFI platform cannot insert modules that aren’t in grubx64.efi. Paradoxically, this means that security-conscious users cannot use grub’s verify module, or employ (near) full disk encryption using cryptodisk and luks. The security benefits of signature verification would reach more users if Fedora automated it by incorporating the process into grub2-mkconfig. For the long-term, to grant flexibility with grub2 modules on secure boot instances, it may be advisable to sign the .mod files in the ‘grub2-efi-x64-modules’ package, modify grub2-mkconfig (or -install) to copy the necessary modules into the EFI partition when required by the user’s configuration and then allow inserting of signed modules in secure boot instances.[…]

https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2

https://www.phoronix.com/scan.php?page=news_item&px=GRUB2-New-EFI-Modules-For-F31

 

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:

https://firmwaresecurity.com/2016/05/21/hackbgrt-changes-windows-boot-logo-on-uefi-systems/

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

See-also:

https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/boot-screen-components

https://blog.fpmurphy.com/2015/07/access-bsrt-information-and-boot-logo-from-uefi-shell.html

Image offset value relative to display

 

Hyper-V UEFI bootloader complexities

[…]Forcing GRUB installation to EFI removable media path does basically the same thing as when Ubuntu installer asks you if you want to force UEFI installation: it installs to the removable media path in the ESP (EFI System Partition). This is fine for environment where no other operating system is present. However if there is another operating system present on the device which depends on this fallback location “removable media path” it will make this system temporary unbootable (you can manually configure GRUB later to boot it if necessary though). Windows installer for example *also* installs to the removable media path in the ESP. All OS installers installing things to this removable media path will conflict with any other such installers and that’s why in Debian (and Ubuntu) installers don’t do this by default. You explicitly have to select UEFI mode during the normal installation (what I did).[…]

https://blog.jhnr.ch/2017/02/23/resolving-no-x64-based-uefi-boot-loader-was-found-when-starting-ubuntu-virtual-machine/

GRUB 2.02 in the works…

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

http://www.phoronix.com/scan.php?page=news_item&px=GRUB-2.02-RC1-Features

https://fosdem.org/2017/schedule/event/grub_new_maintainers/

https://fosdem.org/2017/schedule/event/grub_new_maintainers/attachments/slides/1768/export/events/attachments/grub_new_maintainers/slides/1768/slides.pdf

http://alpha.gnu.org/gnu/grub/grub-2.02~rc1.tar.gz

GRUB and TPM

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

https://firmwaresecurity.com/2015/12/20/new-uefi-patched-grub-legacy/
http://trousers.sourceforge.net/grub.html

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:

http://mjg59.dreamwidth.org/37656.html
https://github.com/mjg59/grub

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:

https://github.com/Sirrix-AG/TrustedGRUB2
https://github.com/Sirrix-AG/TrustedGRUB2/commits/master

Hmm, there’s some UEFI 2.5-centric checks in the Sirrix tree, too:
https://github.com/Sirrix-AG/TrustedGRUB2/commit/c79c59f1295df8ea660f8a858f9532d76a5f67b7

https://www.gnu.org/software/grub/

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.

 

CrowdStrike on building secure burner laptops

Morgan Marquis-Boire posted a pointer to this advise from CrowdStrike on how to build a ‘burner laptop’, for hostile environments. The Arch Linux-based system uses a very interesting configuration, such as embedding GRUB onto the SPI FLash, for the root of trust.

Excerpt from introduction of readme:

A Reasonably Secure Travel Laptop Setup

This repository contains auxiliary scripts and configurations around building a reasonably secure travel laptop using coreboot with a GRUB2 payload. The scripts and configurations have been tested with an ArchLinux setup but should be adaptable to other distributions easily. A reasonably secure travel laptop following the approach laid out here will boot only a signed kernel and initrd and assure user-space integrity with a dm-verity protected root filesystem. If you require confidentiality, it is additionally recommended encrypted the entire filesystem or use a separate, encrypted /home partition. Building coreboot and GRUB2 for your target laptop and flashing the appropriate image is out of the scope of this repository’s contents and documentation. You can find more information on the coreboot Wiki.

[…]

Full article:
https://github.com/CrowdStrike/travel-laptop