diff options
Diffstat (limited to 'site')
| -rw-r--r-- | site/faq/index.php | 156 |
1 files changed, 155 insertions, 1 deletions
diff --git a/site/faq/index.php b/site/faq/index.php index b78e6da..84f5961 100644 --- a/site/faq/index.php +++ b/site/faq/index.php @@ -64,11 +64,26 @@ <li><a href="#install">How do I install libreboot?</a></li> <li><a href="#repugnantpi">How do I programme an SPI flash chip with the Raspberry Pi?</a></li> <li><a href="#bootpassword">How do I set a boot password?</a></li> - <li><a href="#writeprotect">How do I write-protect the flash chip?</a></li> + <li><a href="#writeprotect">How do I write-protect the flash chip?</a> (for example, to protect against firmware-level malware being installed)</li> <li><a href="#biossettings">How do I change the BIOS settings?</a></li> <li><a href="#bootloader">Do I need to install a bootloader when installing GNU/Linux?</a></li> <li><a href="#reinstallos">Do I need to re-flash when I re-install GNU/Linux?</a></li> </ul> + <h2>Freedom questions</h2> + <ul class="cascade"> + <li> + <a href="#blobs">What other blobs exist that libreboot doesn't replace?</a> + <ul> + <li><a href="#blobs-ec">EC (embedded controller) firmware</a></li> + <li><a href="#blobs-hddssd">HDD/SSD firmware</a></li> + <li><a href="#blobs-nic">NIC (ethernet controller<)/a></li> + <li><a href="#blobs-cpu">CPU microcode</a></li> + <li><a href="#blobs-sound">Sound card</a></li> + <li><a href="#blobs-webcam">Web cam</a></li> + <li><a href="#blobs-usbhost">USB host controller</a></li> + </ul> + </li> + </ul> <h2>Operating Systems</h2> <ul class="cascade"> <li><a href="#gnulinux">Can I use GNU/Linux?</a> (yes, you can)</li> @@ -389,6 +404,145 @@ </div> <div> + + <h1>Freedom questions</h1> + + <h2 id="blobs">What other blobs exist that libreboot doesn't replace? <span class="ref">(<a href="#blobs">#blobs</a>)</span></h2> + + <p> + The main freedom issue on any system, is the boot firmware (usually referred to as a BIOS or UEFI). Libreboot replaces the boot firmware + with fully free code, but even with libreboot, there may still be other hardware components in the system (e.g. laptop) that run + their own dedicated firmware, sometimes proprietare. These are on secondary processors, where the firmware is usually read-only, written for very specific tasks. + While these are unrelated to libreboot, technically speaking, it makes sense to document some of the issues here. + </p> + <p> + Note that these issues are not unique to libreboot systems. They apply universally, to most systems. The issues described below + are the most common (or otherwise critical). + </p> + <p> + Dealing with these problems will most likely be handled by a separate project. + </p> + + <h3 id="blobs-ec">EC (embedded controller) firmware <span class="ref">(<a href="#blobs-ec">#blobs-ec</a>)</span></h3> + <p> + Most (all?) laptops have this. The EC (embedded controller) is a small, separate processor that basically processes inputs/outputs + that are specific to laptops. For example: + </p> + <ul> + <li> + When you flick the radio on/off switch, the EC will enable/disable the wireless devices (wifi, bluetooth, etc) and enable/disable + an LED that indicates whether it's turned on or not + </li> + <li> + Listen to another chip that produces temperature readings, adjusting fan speeds accordingly (or turning the fan(s) on/off). + </li> + <li> + Takes certain inputs from the keyboard, e.g. brightness up/down, volume up/down. + </li> + <li> + Detect when the lid is closed or opened, and send a signal indicating this. + </li> + <li> + Etc. + </li> + </ul> + <p> + Alexander Couzens from coreboot (lynxis on coreboot IRC) is working on a free EC firmware replacement for the ThinkPads + that are supported in libreboot. See: + <a href="https://github.com/lynxis/h8s-ec">https://github.com/lynxis/h8s-ec</a> + (not ready yet). + </p> + <p> + Most (all?) chromebooks have free EC firmware. Libreboot is currently looking into supporting a few ARM-based chromebooks. + </p> + <p> + EC is only present on laptops. On desktop/server boards it is absent (not required). + </p> + <p> + <a href="#pagetop">Back to top of page</a> + </p> + + <h3 id="blobs-hddssd">HDD/SSD firmware <span class="ref">(<a href="#blobs-hddssd">#blobs-hdd-ssd</a>)</span></h3> + <p> + HDDs and SSDs have firmware in them, intended to handle the internal workings of the device while exposing a simple, + standard interface (such as AHCI/SATA) that the OS software can use, generically. This firmware is transparent to the user + of the drive. + </p> + <p> + HDDs and SSDs are quite complex, and these days contain quite complex hardware which is even capable of running an entire + operating system (by this, we mean that the drive itself is actually running its own embedded operating system), even GNU/Linux + or BusyBox/Linux. + </p> + <p> + Example attack that malicious firmware could do: substitute your SSH keys, allowing unauthorized remote access by an unknown + adversary. Or maybe substitute your GPG keys. AHCI (SATA) drives also will have DMA, which means that they could read + from system memory; the drive can have its own hidden storage, theoretically, where it could read your LUKS keys and store them + unencrypted for future retrieval by an adversary. + </p> + <p> + With proper IOMMU, it might be possible to mitigate the DMA-related issues. + </p> + <p> + Some proof of concepts have been demonstrated. For HDDs:<br/> + <a href="https://spritesmods.com/?art=hddhack&page=1">https://spritesmods.com/?art=hddhack&page=1</a><br/> + For SSDs:<br/> + <a href="http://www.bunniestudios.com/blog/?p=3554">http://www.bunniestudios.com/blog/?p=3554</a> + </p> + <p> + Viable free replacement firmware is currently unknown to exist. For SSDs, the + <a href="http://openssd-project.org/">OpenSSD</a> project may be interesting. + </p> + <p> + <a href="#pagetop">Back to top of page</a> + </p> + + <h3 id="blobs-nic">NIC (ethernet controller) <span class="ref">(<a href="#blobs-nic">#blobs-nic</a>)</span></h3> + <p> + Ethernet NICs will typically run firmware inside, which is responsible for initializing the device internally. + Theoretically, it could be configured to drop packets, or even modify them. + </p> + <p> + With proper IOMMU, it might be possible to mitigate the DMA-related issues. + </p> + <p> + <a href="#pagetop">Back to top of page</a> + </p> + + <h3 id="blobs-cpu">CPU microcode <span class="ref">(<a href="#blobs-cpu">#blobs-cpu</a>)</span></h3> + <p> + Implements an instruction set. See <a href="#microcode">#microcode</a> for a brief description. + Here we mean microcode built in to the CPU. We are not talking about the updates supplied by the boot firmware + (libreboot does not include microcode updates, and only supports systems that will work without it) + Microcode can be very powerful. No proof that it's malicious, but it could theoretically + </p> + <p> + CPUs often on modern systems have a processor inside it for things like power management. + ARM for example, has lots of these. + </p> + <p> + <a href="#pagetop">Back to top of page</a> + </p> + + <h3 id="blobs-usbhost">USB host controller <span class="ref">(<a href="#blobs-usbhost">#blobs-usbhost</a>)</span></h3> + <p> + Doesn't really apply to current libreboot systems (none of them have USB 3.0 at the moment), but + USB 3.0 host controllers typically rely on firmware to implement the XHCI specification. Some newer + coreboot ports also require this blob, if you want to use USB 3.0. + </p> + <p> + This doesn't affect libreboot at the moment, because all current systems that are supported only + have older versions of USB available. USB devices also don't have DMA (but the USB host controller itself does). + </p> + <p> + With proper IOMMU, it might be possible to mitigate the DMA-related issues (with the host controller). + </p> + <p> + <a href="#pagetop">Back to top of page</a> + </p> + + </div> + + <div> <h1>Operating Systems</h1> <h2 id="gnulinux">Can I use GNU/Linux? <span class="ref">(<a href="#gnulinux">#gnulinux</a>)</span></h2> <p> |