From b19f003358027d07fa66a0e27a792727d9d0fca5 Mon Sep 17 00:00:00 2001 From: Trammell hudson Date: Sun, 21 Jan 2018 10:18:52 -0500 Subject: [PATCH] fixup FAQ a little bit --- FAQ.md | 95 ++++++++++++++++++++++------------------------------------ 1 file changed, 35 insertions(+), 60 deletions(-) diff --git a/FAQ.md b/FAQ.md index e2fe1b2..0d10841 100644 --- a/FAQ.md +++ b/FAQ.md @@ -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.