Over time, there have been many questions asked about libreboot. We have to answer them every time, so it makes sense to document them here instead. More questions and answers will be added here, as time goes by. Back to home page
It is extremely unlikely that any post-2008 Intel hardware will ever be supported in libreboot. The main issues are as follows:
The most glaring issue on modern Intel hardware (beyond year ~2008) is the Management Engine. This is a separate processor that exists in all Intel chipsets past the year ~2006; some systems between those years can have the Management Engine firmware removed (with the ME processor permanently deactivated), but not replaced (due to cryptographic signature checking on the firmware) - see ../docs/hcl/gm45_remove_me.html. The management engine provides remote access capabilities, independently from the running operating system. It has full access to your RAM, and it has full networking support. It also handles the TPM module, AMT (Active Management Technology), Boot Guard and various DRM mechanisms. The ME also performs some basic hardware initialization and power management, on recent systems.
All modern Intel systems built after around the year 2008 (after ICH9) require this blob, and will not boot without it (or will shut down after 30 minutes). Replacing it is impossible, unless you are Intel (only they have the private key, necessary for signing the firmware). The Management Engine is covered on a lot of websites (e.g. me.bios.io, smashthestack.org, the coreboot wiki, wikipedia, FSF blog) and a book titled Platform Embedded Security Technology Revealed (PESTR), published by Apress (ISBN 9781430265719).
The Management Engine processor is an ARC microcontroller. The firmware is based on ThreadX RTOS, which is an embedded operating system designed specifically for those chips. Manufacturers (not just Intel) can pay for a (proprietary) license providing access to the source code, but they are not allowed to share it with anyone. In other words, even if Intel wanted to release the source code for this blob, they could not do so. Even if they did, the ME firmware is cryptographically signed, where the signature is verified at boot time. If you try to use your own modified version of the ME firmware, it will be rejected by the ARC processor and your system will not boot. In other words, the ME firmware is tivoized.
The Management Engine is a giant backdoor, allowing full access to your entire system for malicious adversaries. The libreboot project strongly recommends that you avoid it entirely, and this means avoiding the latest generation of Intel hardware.
All modern x86 CPUs (from Intel and AMD) use what is called microcode. CPUs are extremely complex, and difficult to get right, so the circuitry is designed in a very generic way, where only basic instructions are handled in hardware. Most of the instruction set is implemented using microcode, which is low-level software running inside the CPU that can specify how the circuitry is to be used, for each instruction. The built-in microcode is part of the hardware, and read-only. Both the circuitry and the microcode can have bugs, which could cause reliability issues.
Microcode updates are proprietary blobs, uploaded to the CPU at boot time, which patches the built-in microcode and disables buggy parts of the CPU to improve reliability. In the past, these updates were handled by the operating system kernel, but on all recent systems it is the boot firmware that must perform this task. Coreboot does distribute microcode updates for Intel and AMD CPUs, but libreboot cannot, because the whole point of libreboot is to be 100% free software.
On some older Intel CPUs, it is possible to exclude the microcode updates and not have any reliability issues in practise. All current libreboot systems work without microcode updates (otherwise, they wouldn't be supported in libreboot). However, all modern Intel CPUs require the microcode updates, otherwise the system will not boot at all, or it will be extremely unstable (memory corruption, for example).
Intel CPU microcode updates are signed, which means that you could not even run a modified version, even if you had the source code. If you try to upload your own modified updates, the CPU will reject them. In other words, the microcode updates are tivoized.
On all recent Intel systems, coreboot support has revolved around integrating a blob (for each system) called the FSP (firmware support package), which handles all of the hardware initialization, including memory initialization. Reverse engineering and replacing this blob is almost impossible, due to how complex it is. Even for the most skilled developer, it would take years to replace. Intel distributes this blob to firmware developers, without source.
For years, coreboot has been struggling against Intel. Intel has been shown to be extremely uncooperative in general. Many coreboot developers, and companies, have tried to get Intel to cooperate; namely, releasing source code for the firmware components. Even Google, which sells millions of chromebooks (coreboot pre-installed) have been unable to persuade them.
Even when Intel does cooperate, they still don't provide source code. They might provide limited information (datasheets) under strict corporate NDA (non-disclosure agreement), but even that is not guaranteed. Even ODMs and IBVs can't get source code from Intel, in most cases (they will just integrate the blobs that Intel provides).
Recent Intel graphics chipsets also require firmware blobs.
Basically, all Intel hardware from year 2010 and beyond will never be supported by libreboot. The libreboot project is actively ignoring all modern Intel hardware at this point, and focusing on alternative platforms.
Probably not (it uses latest generation of Intel hardware - see #intel). It would be nice if libreboot could run on these laptops, but it's extremely unlikely due to the fact that there are signed proprietary blobs that cannot be replaced and are required (Intel Management Engine and CPU microcode updates). It uses the proprietary Intel FSP blob for the entire hardware initialization, which Intel won't provide the source code for. The Video BIOS (initialization firmware for the graphics hardware) is also proprietary, and will likely take years to reverse engineer and replace (once again, Intel won't provide the source code).
The latest ThinkPad generation supported in libreboot are the ones using the GM45 (ICH9) chipsets, such as the ThinkPad X200 or T400. See #intel. Newer Intel ThinkPads will probably never be supported in libreboot, due to the fact that there are signed blobs that cannot be replaced (e.g. Intel Management Engine). Newer Lenovo laptops are also starting to use the Intel Boot Guard, which specifically blocks the use of firmware that has not been signed by the OEM.
Coreboot does have support for some more recent Lenovo laptops, but libreboot cannot support most of these.
A common issue with desktop hardware is the Video BIOS. Libreboot has to initialize the graphics chipset, but most graphics cards lack a free Video BIOS for this purpose. Some desktop motherboards supported in coreboot do have onboard graphics chipsets, but these also require a proprietary Video BIOS, in most cases.
There is the XGI Z9s PCI-E graphics card, documented under Board Ports in ../docs/tasks.html, which might be viable for you.
Although not desktop hardware (it's a server board), libreboot does support the ASUS KFSN4-DRE, with more server hardware support on the horizon, as outlined in ../docs/tasks.html. These boards have onboard graphics chipsets for which free native graphics initialization code does exist (as well as free initialization code for everything else in the boot firmware). These systems can be used to build very high-powered workstations, though it will be quite a bit bigger (physically) and more expensive than a standard desktop computer. However, it is the best option currently available in libreboot for this purpose.
Most likely not. First, you must consult coreboot's own hardware compatibility list at http://www.coreboot.org/Supported_Motherboards and, if it is supported, check whether it can run without any proprietary blobs in the ROM image. If it can: wonderful! Libreboot can support it, and you can add support for it using the notes at ../docs/maintain/index.html. If not, then you will need to figure out how to reverse engineer and replace (or remove) those blobs that do still exist, in such a way where the system is still usable in some defined way.
For those systems where no coreboot support exists, you must first port it to coreboot and, if it can then run without any blobs in the ROM image, it can be added to libreboot. See: Motherboard Porting Guide (this is just the tip of the iceberg!)
Please note that board development should be done upstream (in coreboot) and merged downstream (into libreboot). This is the correct way to do it, and it is how the libreboot project is coordinated so as to avoid too much forking of the coreboot source code.
TODO
Libreboot has support for some AMD platforms, with more on the horizon. See ../docs/hcl/index.html.
More AMD-related information will be added to this page at a later date.
See ../docs/install/index.html
The RPi can be used to install libreboot onto a system that uses SPI flash, but libreboot intentionally doesn't document it. Why? Blobs. The RPi requires a blob for the integrated video chipset, in order to boot. This was true of the original RPi, and has continued to be true for all subsequent revisions of the hardware. The RPi people clearly don't give a damn about your freedom, so we don't give a damn about endorsing them.
There are other, more freedom-friendly SPI programmers available, documented on ../docs/install/index.html.
If you are using the GRUB payload, you can add a username and password (salted, hashed) to your GRUB configuration that resides inside the flash chip. The following guides (which also cover full disk encryption, including the /boot/ directory) show how to set a boot password in GRUB: ../docs/gnulinux/encrypted_trisquel.html and ../docs/gnulinux/encrypted_parabola.html
By default, there is no write-protection on a libreboot system. This is for usability reasons, because most people do not have easy access to an external programmer for re-flashing their firmware, or they find it inconvenient to use an external programmer.
On some systems, it is possible to write-protect the firmware, such that it is rendered read-only at the OS level (external flashing is still possible, using dedicated hardware). For example, on current GM45 laptops (e.g. ThinkPad X200, T400), you can write-protect (see ../docs/hcl/gm45_remove_me.html#ich9gen). Depending on your flash chip, you can also write-protect the i945 laptops, such as the ThinkPad X60 or T60 (see ../docs/security/x60_security.html) and ../docs/security/t60_security.html for links to a video explaining it).
It's possible to write-protect on all libreboot systems, but the instructions need to be written. The documentation is in the main git repository, so you are welcome to submit patches adding these instructions.
Libreboot actually uses the GRUB payload. More information about payloads can be found at coreboot.org/Payloads.
Libreboot inherits the modular payload concept from coreboot, which means that pre-OS bare-metal BIOS setup programmes are not very practical. Coreboot (and libreboot) does include a utility called nvramtool, which can be used to change some settings. You can find nvramtool under coreboot/util/nvramtool/, in the libreboot source archives.
The -a option in nvramtool will list the available options, and -w can be used to change them. Consult the nvramtool documentation on the coreboot wiki for more information.
In practise, you don't need to change any of those settings, in most cases.
Libreboot integrates the GRUB bootloader already, as a payload. This means that the GRUB bootloader is actually flashed, as part of the boot firmware (libreboot). This means that you do not have to install a boot loader on the HDD or SSD, when installing GNU/Linux. You'll be able to boot GNU/Linux just fine, using the bootloader (GRUB) that is in the flash chip.
This also means that even if you remove the HDD or SSD, you'll still have a functioning bootloader installed which could be used to boot a live GNU/Linux distribution installer from a USB flash drive. See .../docs/gnulinux/grub_boot_installer.html
Not anymore. Recent versions of libreboot (using the GRUB payload) will automatically switch to a GRUB configuration on the HDD or SSD, if it exists. You can also load a different GRUB configuration, from any kind of device that is supported in GRUB (such as a USB flash drive). For more information, see ../docs/gnulinux/grub_cbfs.html
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 proprietary. 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.
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).
Dealing with these problems will most likely be handled by a separate project.
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:
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: https://github.com/lynxis/h8s-ec (not ready yet).
Most (all?) chromebooks have free EC firmware. Libreboot is currently looking into supporting a few ARM-based chromebooks.
EC is only present on laptops. On desktop/server boards it is absent (not required).
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.
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.
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.
With proper IOMMU, it might be possible to mitigate the DMA-related issues. USB drives (flash drive, HDD, etc) can be used, to avoid DMA.
Some proof of concepts have been demonstrated. For HDDs:
https://spritesmods.com/?art=hddhack&page=1
For SSDs:
http://www.bunniestudios.com/blog/?p=3554
Viable free replacement firmware is currently unknown to exist. For SSDs, the OpenSSD project may be interesting.
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.
With proper IOMMU, it might be possible to mitigate the DMA-related issues. A USB NIC can also be used, which does not have DMA.
Implements an instruction set. See #microcode 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
There isn't really a way to solve this, unless you use a CPU which does not have microcode. (ARM CPUs don't, but most ARM systems require blobs for the graphics hardware at present, and typically have other things like soldered wifi which might require blobs)
CPUs often on modern systems have a processor inside it for things like power management. ARM for example, has lots of these.
Sound hardware (integrated or discrete) typically has firmware on it (DSP) for processing input/output. Again, a USB DAC is a good workaround.
Webcams have firmware integrated into them that process the image input into the camera; adjusting focus, white balancing and so on. Can use USB webcam hardware, to work around potential DMA issues; integrated webcams (on laptops, for instance) are discouraged by the libreboot project.
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.
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).
With proper IOMMU, it might be possible to mitigate the DMA-related issues (with the host controller).
Absolutely! GNU/Linux is well-tested in libreboot, and highly recommended. See installing GNU/Linux and booting GNU/Linux.
Any recent distribution should work, as long as it uses KMS (kernel mode setting) for the graphics.
The Free Software Foundation maintains a list of free GNU/Linux distributions, certified to distribute and endorse free software, exclusively.
Unknown. Probably not. Feel free to try it, and report your findings.
GNU Hurd is a microkernel developed by the GNU project, and was (still is) intended to be the kernel for the GNU operating system. For historical reasons, Linux became the primarily adopted kernel (the libreboot project urges everyone to install and use linux-libre on their GNU systems), and was adapted for use with the GNU system. This is why we say GNU/Linux. Read the GNU/Linux FAQ.
Potentially. It may be possible to boot most BSD systems if you use the SeaBIOS payload. Most BSD systems seem to require a full Video BIOS implementation, which libreboot lacks for the most part, so you won't have a visual display, but you might be able to use an EHCI debug and/or serial console.
FreeBSD is rumoured to be somewhat compatible (with the GRUB payload, even), when booting with text-mode graphics initialization, but you probably won't be able to use X11.
For the most part, BSD systems remain untested in libreboot. BSD systems contain blobs, so do beware.
Windows is incompatible with libreboot, and will probably remain so. Never use Windows.
Unknown. Probably not.