Security: Difference between revisions

From coreboot
Jump to navigation Jump to search
(13 intermediate revisions by the same user not shown)
Line 3: Line 3:
<div style="color:red">This page is work in progress!</div>
<div style="color:red">This page is work in progress!</div>


== Common security features ==
== Free software ==
=== Security fixes ===
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.


* Boot password (like BIOS password)
Examples:
* Signature verification - option to boot from payload only signed images
* [https://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=ce2564ac519fd974eeaa070ccb30d5a12e0c3334 Fix for the memory sinkhole issue]
[[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.
Security fixes are usually mentioned in coreboot ChangeLog on the blog.


* RAM wiping after each boot
=== Coreboot ===
Note that while coreboot itself is free software, many boards still use blobs. Some however don't require any.
 
=== 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. SMM is more powerful than ring0. 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.
 
Given the above, being able to know what your boot fimrware does is very important.
 
=== Reproducible builds ===
Coreboot is working on reproducible builds. That will permit to verify that a given binary corresponds to a given source code.
 
However this isn't sufficient to verify that you are running the right binary:
 
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) another binary than the one in the flash chip.
 
== Existing security features ==
Given that, with coreboot, the hardware initialization is separated from the boot logic, many security features are implemented by payloads. Nevertheless, coreboot implement some security features.
 
{| class="wikitable"  border="1"
!
! Coreboot
! GRUB
! SeaBIOS
! Depthcharge
! Tianocore
|-
! Password verification
| No
| style="background:lime" | Yes
| No
| ?
|
|-
! Signature verification
| style="background:lime" | Yes
| style="background:lime" | Yes
| No
| style="background:lime" | Yes
|
|-
! Can open encrypted partition
| No
| style="background:lime" | Yes
| No
| No
|
|}
 
== 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.
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.
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 ==
== Current BIOS issues ==

Revision as of 01:04, 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.

This page is work in progress!

Free software

Security fixes

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.

Examples:

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

Coreboot

Note that while coreboot itself is free software, many boards still use blobs. Some however don't require any.

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. SMM is more powerful than ring0. 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.

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

Reproducible builds

Coreboot is working on reproducible builds. That will permit to verify that a given binary corresponds to a given source code.

However this isn't sufficient to verify that you are running the right binary:

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) another binary than the one in the flash chip.

Existing security features

Given that, with coreboot, the hardware initialization is separated from the boot logic, many security features are implemented by payloads. Nevertheless, coreboot implement some security features.

Coreboot GRUB SeaBIOS Depthcharge Tianocore
Password verification No Yes No ?
Signature verification Yes Yes No Yes
Can open encrypted partition No Yes No No

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.

Current BIOS issues

RAM wiping

SMI issues

ATA issues

Firewire issues

TPM issues

Retrieved from "https://www.coreboot.org/index.php?title=Security&oldid=17774"