Security

Introduction

This page explains how coreboot can help with various security aspects of your system, compared to proprietary/closed-source boot firmware implementations(BIOS/EFI/UEFI). It doesn't however address issues such as the Intel Management Engine or AMD PSP.

Free software

coreboot

Note that while coreboot itself is free software, many boards still use blobs. Some however don't require any. If so they are typically supported by Libreboot, a 100% free software coreboot distribution.

Security fixes

Fixes can take months before being available on non-free firmwares, if you are lucky enough to have them. With free software boot fimrwares, security issues can be fixed, and in coreboot many are.

Examples:

• Fix for the memory sinkhole issue

Security fixes are usually mentioned in coreboot ChangeLog on the blog.

Using proprietary software parts in coreboot, such as proprietary RAM initialization, will make you dependent on the producer of that software to fix security issues affecting it.

• You still can get fixes or fix yourself issues that affects the free software part.
• Integrating back the vendor fixes might be faster than with proprietary vendor BIOSes.
• However the vendor might not do such fixes for older hardware, and access to the source code might be required to fix the issue.

Auditable code

Because the boot firmware is the first code that executes on the main CPU, it's an interesting target for rootkits:

• The code that runs first has to load what runs next, so it can patch it. That patch can then in turn patch what's next and so on.
• The code that runs first can setup SMM on X86 or TrustZone on some ARM SOCs. SMM/Trust zone are more powerful than ring0. On x86 devices, non-free boot firmwares have a tendency to put a lot of code to run in SMM. In contrast coreboot keep it to a minimum.
• Being stored in a flash chip, separately from the OS and its data, non-free boot firmware have a tendency not to be updated by the end user, nor reflashed externally. That permits a very high persistence.

Given the above, being able to know what your boot firmware does is very important.

Reproducible builds

coreboot has reproducible builds. That permits to verify that a given binary corresponds to a given source code. This should work out of the box.

There is even a way to verify that the same code produces the same binary regardless of the git revision with:

$ make BUILD_TIMELESS=1

However reproducible builds isn't sufficient to verify that you are really running the binary you flashed:

Dumping the flash chip externally is strongly advised for that, since some chipsets makes it too easy for the SMM code to give back (to Flashrom) a binary than differs from the one in the flash chip. The same chipset mechanism also makes it too easy to write a modified version to the flash.

If you do not trust the computer dumping the flash externally and can't setup proper flash write protection (patches for it were not merged yet at the time of writing) you can get around that by verifying the flash chip content with unrelated computers, while keeping the computer you read the flash from offline. This way no computer can predict if it will be the last to verify the flash chip, and so covertly modifying it will be risky since it can be detected.

Existing security features

Given that, with coreboot, the hardware initialization is separated from the boot logic, many security features only makes sense when implemented in payloads. Nevertheless, coreboot implement some security features.

	coreboot	GRUB	SeaBIOS	Depthcharge	Tianocore
Password verification	No	Yes	No	?
Signature verification	Yes	Yes	No<ref>This can be achieved by configuring SeaBIOS to only load an IPXE option rom, that in turn verifies signatures. Loading other option rom has also to be avoided. This is possible on some laptops for instance.</ref>	Yes
Can open encrypted partition	No	Yes	No	No

Resisting to "external" attacks

If we, for now, start by assuming that coreboot and what resides in the boot flash is trusted, we then might still have other untrusted chips in the same device:

The Embedded controller

Some laptops, like the chromebooks, do have free software on the embedded controller. This is the way to go. However some laptops don't.

This chip usually handles:

• The keyboard. This can be abused to do a keylogger.
• Power switches to wifi/bluetooth/data-modem
• On some thinkpads it controls a LED to illuminate the keyboard. This results in having a long wire that goes from the EC to that light. This can be abused as an antenna.

Since coreboot has to talk to such chip, input comming from such chip, such as its firmware revision should be considered as untrusted.

Storage medium firmwares

The following storage mediums typically use non-free firmwares:

• Hard disks, SSD<ref>The OpenSSD project (http://www.openssd-project.org/wiki/The_OpenSSD_Project) seem great for developing free software SSDs, but its form factor is not very convenient for laptops</ref>
• MMC/SD/uSD cards uses firmwares<ref>See bunny's work for more details: http://www.bunniestudios.com/blog/?page_id=3592</ref>.
• cdrom/DVD/blueray (the cdrom drive has a firmware).

If we assume that the hard disk firmware is potentially malicious, we then can workaround it by making sure that the code stored on that disk is not modified on the fly by the hard disk firmware.

To do that we can take advantage of the fact that we run code from the boot flash first, which doesn't have such issue.

Code signing and encryption can be used to do that, however care must be taken not to be vulnerable to TOCTU(Time of check, time of use) attacks.

Code signing

• GRUB can check files signature
• dm-verity implements integrity checking at the partition level, but that result in making it read-only.

Encryption

• GRUB has support for opening encrypted partitions (and LVM).

DMA issues

DMA is often understood as a way to access the RAM independently of the CPU.<ref> https://en.wikipedia.org/wiki/Direct_memory_access </ref> However, DMA is, in a more broad context, just a way to do "memory to memory" transfers. That might not involve the main CPU RAM at all, like with SATA's DMA.

Bus capable of accessing the main CPU's RAM:

• PCI
• PCI Express

Bus not capable of accessing the main CPU RAM:

• Serial port, Parallel port, USB

References for the current BIOS issues

RAM wiping

• http://citp.princeton.edu/memory/
• Coreinfo as demo payload for coreboot, showing your RAM contents after a cold boot.

SMI issues

• http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot.pdf
• http://tracker.coreboot.org/trac/coreboot/ticket/42

ATA issues

• http://coreboot.org/pipermail/coreboot/2005-May/011686.html
• http://www.heise.de/ct/english/05/08/172/

Firewire issues

• http://md.hudora.de/presentations/firewire/
• http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-dma-part-1-overview-and-mitigation

TPM issues

• http://tracker.coreboot.org/trac/coreboot/ticket/49

Guides, tutorials, HOWTOs

• Trustworthy flashing: How to safely flash an image, externally, from untrustworthy computers.
• From trustworthy flash to trustworthy OS: Now that we flashed an image, how do we safely install an OS?

Ideas

RAM wiping after each boot

This is not very useful: The most interesting time would be right before power-off, which could be implemented in SMM. Unfortunately a cautious attacker just pulls the plug.

To prevent reading data after a reboot, a payload could be adapted to clean out memory. Using applications that manage sensible data sensibly (ie. wipe after use) is still a better solution.

Protecting against DMA attacks

At boot, the RAM isn't initialized nor functional. This is the boot fimrware's task. Having a free software boot firmware gives us the opportunity to try to never leave the system RAM unprotected from such attacks. The idea would be to try to initialize the IOMMU before activating the RAM.

See also

• Binary_situation

References

<references>