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
The probability is currently estimated to be below 1%, 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). 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.
On all modern Intel systems built after around the year 2008 (after ICH9) require this blob, and will not boot without it. Replacing it is impossible, unless you are Intel (only they have the private key, necesarry for signing the firmware). The Management Engine is covered on lots 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.
The Management Engine is a giant backdoor, allowing full access to your entire system for malicious adversaries.
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.
On all recent Intel systems, coreboot support has revolved around integrating a blob (for each system) called the FSP (firmware support package), which handles most of the hardware initialization, including memory initialization. At present, it is believed that this can be replaced, but it will require a lot of work on reverse engineering which will likely take many years. Intel distributes the FSP blob to firmware developers (including coreboot).
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 (Management Engine, mandatory CPU microcode updates). Also, rumour has it that not even coreboot has support yet for these systems.
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 download (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
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 access to an external programmer for re-flashing their firmware.
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.
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. For more information, see ../docs/gnulinux/grub_cbfs.html
Absolutely! GNU/Linux is well-tested in libreboot, and highly recommended. See installing GNU/Linux and booting GNU/Linux.
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 the 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.
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.