summaryrefslogtreecommitdiffstats
path: root/site
diff options
context:
space:
mode:
Diffstat (limited to 'site')
-rw-r--r--site/faq/index.php156
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&amp;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>