mirrors/linuxboot
1
0
Fork 0
mirror of https://github.com/linuxboot/linuxboot synced 2024-11-21 15:50:58 +00:00
Code Issues Packages Projects Releases Wiki Activity

fixup FAQ a little bit

Browse Source
This commit is contained in:
Trammell hudson 2018-01-21 10:18:52 -05:00
parent 32887e9786
commit b19f003358
Failed to extract signature
1 changed files with 35 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

95
FAQ.md
View File

@ -1,7 +1,7 @@
Frequently Asked Questions about Heads
Frequently Asked Questions about LinuxBoot
===
Why replace UEFI with coreboot?
Why replace UEFI with LinuxBoot?
---
While Intel's edk2 tree that is the base of UEFI firmware is open source,
the firmware that vendors install on their machines is proprietary and
@ -15,11 +15,32 @@ with network device drivers, graphics, USB, TCP, https, etc, etc, etc.
All of these features represents increased "surface area" for attacks,
as well as unnecessary complexity in the boot process.
coreboot is open source and focuses on just the code necessary to bring
the system up from reset. This minimal code base has a much smaller
surface area and is possible to audit. Additionally, self-help is
possible if custom features are required or if a security vulnerability
needs to be patched.
LinuxBoot replaces both UEFI as well as grub, which is has its own OS
worth of drivers, with the fairly well tested and trusted Linux kernel.
Self-help is possible if custom features are required or if security
vulnerabilities need to be patched, and the flexibility of the `initrd`
runtime allows users to tailor their "firmware" to their needs.
Why keep the vendor blobs?
---
LinuxBoot retains the vendor's PEI section of their UEFI firmware, which
is necessary for doing things like chipset initialization, memory controller
setup, CPU interconect. These functions are not documented by the CPU vendors,
so it is necessary to reuse the proprietary pieces -- even coreboot uses
the Intel provided FSP for these functions on modern laptops.
Additionally the Bootguard ACM, on systems that support it, must be signed by
Intel and as a result we are not able to replace that part of the early
startup code.
Where can I learn more about LinuxBoot?
---
* [LinuxBoot.org](https://linuxboot.org)
* [Ron Minnich's Open Source Summit presentation](https://www.youtube.com/watch?v=iffTJ1vPCSo)
* [Trammell Hudson's 34C3 presentation](https://trmm.net/LinuxBoot_34c3)
* [Install instructions for the R630](https://trmm.net/NERF)
What's wrong with UEFI Secure Boot?
@ -36,10 +57,6 @@ hashes on the coreboot payload. This works well for the specialized
Chrome OS on the Chromebook, but is not as flexible as a measured
boot solution.
By moving the verification into the boot scripts we're able to have
a much flexible verification system and use more common tools like PGP
to sign firmware stages.
What about Trusted GRUB?
---
@ -55,15 +72,17 @@ drivers for all the different boot devices, as well as filesystems.
This duplicates the code that exists in the Linux kernel and has its
own attack surface.
Using coreboot and Linux as a boot loader allows us to restrict
the signature validation to keys that we control. We also have one code
base for the device drivers in the Linux-as-a-boot-loader as well
as Linux in the operating system.
Using Linux as a boot loader allows us to restrict the signature
validation to keys that we control. We also have one code base for the
device drivers in the Linux-as-a-boot-loader as well as Linux in the
operating system.
What is the concern with the Intel Management Engine?
---
"Rootkit in your chipset", "x86 considered harmful", etc
"Rootkit in your chipset", "x86 considered harmful", etc.
The [ME cleaner](https://github.com/corna/me_cleaner) can be used to reduce
the size of the ME firmware, although we can't turn it off entirely.
How about the other embedded devices in the system?
@ -76,47 +95,3 @@ Should we be concerned about the binary blobs?
Maybe. x230 has very few (MRC) since it has native vga init.
Why use ancient Thinkpads instead of modern Macbooks?
---
coreboot support, TPM, nice keyboards, cheap to experiment on.
How likely are physical presence attacks vs remote software attacks?
---
Who knows.
Defense in depth vs single layers
---
Yes.
is it worth doing the hardware modifications?
---
Depends on your threat model.
Should I validate the TPMTOTP on every boot?
---
Probably. I want to make it also do it at S3.
suspend vs shutdown?
---
S3 is subject to cold boot attacks, although they are harder to
pull off on a Heads system since the boot devices are constrained.
However, without tpmtotp in s3 it is hard to know if the system is in
a safe state when the xscreensaver lock screen comes up. Is it a fake
to deceive you and steal your login password? Maybe! It wouldn't get
your disk password, which is perhaps an improvement.
Disk key in TPM or user passphrase?
---
Depends on your threat model. With the disk key in the TPM an attacker
would need to have the entire machine (or a backdoor in the TPM)
to get the key and their attempts to unlock it can be rate limited
by the TPM hardware.
However, this ties the disk to that one machine (without having to
recover and type in the master key), which might be an unacceptable risk
for some users.