Security: Difference between revisions
No edit summary |
|||
| Line 4: | Line 4: | ||
== Free software == | == Free software == | ||
Recently many security issues had to be fixed in the boot firmware. Examples can be found on the ChangeLogs blog articles. | Recently many security issues had to be fixed in the boot firmware. Examples can be found on the coreboot ChangeLogs blog articles. | ||
Fixes can take months before being available on non-free firwmares, if you are lucky enough to have them. | Fixes can take months before being available on non-free firwmares, if you are lucky enough to have them. | ||
With free software boot fimrwares, security issues can be fixed, and in coreboot many are. | With free software boot fimrwares, security issues can be fixed, and in coreboot many are. | ||
Revision as of 00:28, 17 January 2016
This page explains how coreboot can help with various security aspects of your system, compared to closed-source, legacy BIOS/EFI/firmware implementations.
Free software
Recently many security issues had to be fixed in the boot firmware. Examples can be found on the coreboot ChangeLogs blog articles.
Fixes can take months before being available on non-free firwmares, if you are lucky enough to have them. With free software boot fimrwares, security issues can be fixed, and in coreboot many are.
Common security features
- Boot password (like BIOS password)
- Signature verification - option to boot from payload only signed images
Bayou / coreinfo / GRUB2 have "BIOS password"-like feature, using SHA-1 hashes stored in NVRAM or the (flash) ROM chip. GRUB2 can also do signature verification of on-disk operating systems. TianoCore could probably be adapted to support either, too.
Both features are in the payload domain since coreboot doesn't provide a user interface.
- 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.
- Support booting from encrypted block devices/volumes
GRUB2 can do that.
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