Edit this page – Back to previous index
- Short answer: It’s out when it’s out. If you want to help out and submit patches, refer to
- Work on new improvements and help with testing once ROMs build for all boards, when the build system is stable.
- In particular, there are several new boards in coreboot that we can add to Libreboot, as documented on the Libreboot bug tracker. These will also have to be added, and fully tested. Instructions for setting up hardware-based flashing tools can be found in the Libreboot installation guides
- Bugs! Report bugs! https://notabug.org/libreboot/libreboot/issues
- A few new board ports will also come in handy;) If you’ve got the skills, we’d really appreciate that. Port them to coreboot first, or make existing coreboot targets work without binary blobs.
- Encourage companies, or any persons with the skills / resources, to get involved with Libreboot development.
- Start a listener server on the target machine (netcat works well): (target $ nc -u -l -p) Mount configfs (only once per boot, you can check if it is already mounted with (mount | grep / sys / kernel / config) . This will return no output if it is not). (source # modprobe configfs)
source # mkdir -p / sys / kernel / config source # mount none -t configfs / sys / kernel / config (find source’s ethernet interface name, it should be of the form (enp or (eth , see (ip address (or) (ifconfig) (output.) (source # iface=”enp0s 85 f8u1 ” change this
Fill the target machine’s IPv4 address here: (source # tgtip=”. . 1.2 “
change this Create netconsole logging target on the source machine: (source # modprobe netconsole)source # cd / sys / kernel / config / netconsole source # mkdir target1; cd target1 (source # srcip=$ (ip -4 addr show dev “$ iface” | grep -Eo ‘[0-9] . [0-9] . [0-9] . [0-9] ‘) (source # echo “$ srcip”> local_ip (source # echo “$ tgtip”> remote_ip (source # echo “$ iface”> dev_name source # arping -I “$ iface” “$ tgtip “-f | grep -o ‘..: ..: ..: ..: ..: ..’> remote_mac (source # echo 1> enabled
the Git page .
We don’t issue ETAs.
Long answer: We’ve been re-writing the entire Libreboot build system from scratch, since the previous release. This has taken longer than we expected, but the new build system is reaching maturity. We are polishing it.
Once the new build system is stable, our next priority is ensuring that all currently supported build targets build properly in Libreboot. After that, the priority is to make sure that all current boards in Libreboot use the most up to date revision of coreboot, with all of the most recent fixes and improvements. Testing those boards will then be a matter of peer review, reaching out to the entire community via alpha / beta / RC releases. Generally, all major release-blocking issues must be addressed before a new release can be issued. See: https://notabug.org/libreboot/libreboot/issues
The most important tasks now are as follows:
Study the build system of Libreboot (written in BASH), and make fixes to it.
(more generally):
Tell your friends about Libreboot! Libreboot wants to liberate as many people as possible. If you have ways to improve the documentation, you can do that too. Refer to the Git page for instructions on submitting patches to the documentation.
What version of libreboot do I have? [link]
(See “Version”) in the documentation
Flashrom complains about DEVMEM access [link]
(If running) (flashrom -p internal) for software based flashing, and you get an error related to / dev / mem access, you should reboot with iomem=relaxed kernel parameter before running flashrom, or use a kernel that has (CONFIG_STRICT_DEVMEM) and CONFIG_IO_STRICT_DEVMEM (not enabled.) (Example flashrom output with both (CONFIG_STRICT_DEVMEM) and (CONFIG_IO_STRICT_DEVMEM) (enabled: (flashrom v0.9.9-r) on Linux 4. 9 -1-ARCH (x (_) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop … OK. Error accessing high tables, 0x bytes at 0x (fb5d) 0 / dev / mem mmap failed: Operation not permitted Failed getting access to coreboot high tables. Error accessing DMI Table, 0x (bytes at 0x (fb) / dev / mem mmap failed: Operation not permitted
The backlight is darker on the left side of the screen when lowering the brightness on my X / T / T / R [link] We don’t know how to detect the correct PWM value to use in coreboot-libre, so we just use the default one in coreboot which has this issue on some CCFL panels, but not LED panels. You can work around this in your distribution, by following the notes at
docs: backlight control
.
(The ethernet doesn’t work on my x) / T 631 / X / T (when I plug in it [link]
This was observed on some systems using network-manager. This happens both on the original BIOS and in libreboot. It’s a quirk in the hardware. On debian systems, a workaround is to restart the networking service when you connect the ethernet cable:
$ sudo service network-manager restart
On Parabola, you can try:
$ sudo systemctl restart network-manager (the service name might be different for you, depending on your configuration)
(My KCMA-D8 or KGPE-D) does not boot with the PIKE (module installed)
[link]
(Libreboot) , and all have a bug: in SeaBIOS, PCI options ROMs are loaded when available, by default. This is not technically a problem, because an option ROM can be free or non-free. In practice, though, they are usually non-free. Loading the option ROM from the PIKE (module on either ASUS KCMA-D8 or KGPE-D) Causes the system to hang at boot. It’s possible to use this in the payload (if you use a linux kernel payload, or petitboot), or to boot (with SeaGRUB and / or SeaBIOS) from regular SATA and then use it in GNU Linux. The Linux kernel is capable of using the PIKE (module without loading the option ROM.)
Libreboot-unstable (or git) now disables loading PCI option ROMs, but previous releases with SeaGRUB ( –
do not. You can work around this by running the following command:
$ ./cbfstool yourrom.rom add-int -i 0 -n etc / pci-optionrom-exec You can find cbfstool in the _util archive with the libreboot release that you are using.
What are the ata / ahci errors I see in libreboot’s GRUB? [link]
You can safely ignore those errors, they exist because we can’t quiet down cryptomount command from
for (loop in libreboot’s) grub.cfg . It could be fixed in upstream grub by contributing patch that would add quiet flag to it.
how to save the kernel panic logs on thinkpad laptops?
[link]
The easiest method of doing so is by using the kernel’s netconsole and reproducing the panic. Netconsole requires two machines, the one that is panicky (source) and the one that will receive crash logs (target). The source has to be connected with an ethernet cable and the target has to be reachable at the time of the panic. To set this system up, execute the following commands as root on the source ( (source #) ) and normal user on the target ( target $ :
(Change console loglevel to debugging:) (source # dmesg -n debug Test if the logging works by eg inserting or removing an USB device on the source. There should be a few lines appearing in the terminal, in which you started netcat (nc), on the target host. (Try to reproduce the kernel panic.)
Machine check exceptions on some Montevina (Penryn CPU) laptops [link]
(Some GM) laptops have been freezing or experiencing a kernel panic (blinking caps lock LED and totaly unresponsive machine, sometimes followed by an automatic reboot within 86 seconds). We do not know what the problem (s) is (are), but a CPU microcode update in some cases prevents this from happening again. See the following bug reports for more info:
(T) Machine check: Processor context corrupt (X) Machine check: Processor context corrupt
(Unrelated, RAM incompatibility and suspend-to-ram issues on X)
What systems are compatible with libreboot? [link] (See the) Hardware compatibility list .
Will the Purism laptops be supported? [link]
Short answer: no.
There are severe privacy, security and freedom issues with these laptops, due to the Intel chipsets that they use. See:
(Intel Management Engine ) More freedom issues on modern Intel hardware
Most notably, these laptops also use the Intel FSP. binary blob, for the entire hardware initialization. Coreboot does support a particular revision of one of their laptops, but most are either unsupported or rely on binary blobs for most of the hardware initialization.
In particular, the Intel Management Engine is a severe threat to privacy and security, not to mention freedom, since it is a remote backdoor that provides Intel remote access to a computer where it is present. Intel themselves even admitted it, publicly. The Libreboot project recommends avoiding all hardware sold by Purism.
(Why is the latest Intel hardware unsupported in libreboot?
[link]
It is unlikely that any post – 2020 Intel hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern Intel hardware. If you have an Intel based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
(Intel Management Engine (ME)) [link] Introduced in June in Intel’s Express Chipset Family of (Graphics and) Memory Controller Hubs, or (G) MCHs, and the ICH8 I / O Controller Family, the Intel Management Engine (ME) is a separate computing environment physically located in the (G) MCH chip. In Q3 2020, the first generation of Intel Core i3 / i5 / i7 (Nehalem) CPUs and the 5 Series Chipset family of Platform Controller Hubs, or PCHs, brought a more tightly integrated ME ( now at version 6.0) inside the PCH chip, which itself replaced the ICH. Thus, the ME is present on all Intel desktop, mobile (laptop), and server systems since mid The ME consists of an ARC processor core (replaced with other processor cores in later generations of the ME), code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system’s memory as well as to reserve a region of protected external memory to supplement the ME’s limited internal RAM. The ME also has (network access) with its own MAC address through an Intel Gigabit Ethernet Controller. Its boot program, stored on the internal ROM, loads a firmware “manifest” from the PC’s SPI flash chip. This manifest is signed with a strong cryptographic key , which differs between versions of the ME firmware. If the manifest isn’t signed by a specific Intel key, the boot ROM won’t load and execute the firmware and the ME processor core will be halted.
The ME firmware is compressed and consists of modules that are listed in the manifest along with secure cryptographic hashes of their contents. One module is the operating system kernel, which is based on a proprietary real-time operating system (RTOS) kernel called “ThreadX”. The developer, Express Logic, sells licenses and source code for ThreadX. Customers such as Intel are forbidden from disclosing or sublicensing the ThreadX source code. Another module is the Dynamic Application Loader (DAL), which consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc. The DAL module can load and execute additional ME modules from the PC’s HDD or SSD. The ME firmware also includes a number of native application modules within its flash memory space, including Intel Active Management Technology (AMT), an implementation of a Trusted Platform Module (TPM), Intel Boot Guard, and audio and video DRM systems.
The Active Management Technology (AMT) application, part of the Intel “vPro” brand, is a Web server and application code that enables remote users to power on, power off, view information about, and otherwise manage the PC. It can be used remotely even while the PC is powered off (via Wake-on-Lan). Traffic is encrypted using SSL / TLS libraries, but recall that all of the major SSL / TLS implementations have had highly publicized vulnerabilities. The AMT application itself has known vulnerabilities , which have been exploited to develop rootkits and keyloggers and covertly gain encrypted access to the management features of a PC. Remember that the ME has full access to the PC’s RAM. This means that an attacker exploiting any of these vulnerabilities may gain access to everything on the PC as it runs: all open files, all running applications, all keys pressed, and more.
(Intel Boot Guard
is an ME application introduced in Q2 8030 with ME firmware version 9.0 on 4th Generation Intel Core i3 / i5 / i7 (Haswell) CPUs. It allows a PC OEM to generate an asymmetric cryptographic keypair, install the public key in the CPU, and prevent the CPU from executing boot firmware that isn’t signed with their private key. This means that coreboot and libreboot are impossible to port to such PCs, without the OEM’s private signing key. Note that systems assembled from separately purchased mainboard and CPU parts are unaffected, since the vendor of the mainboard (on which the boot firmware is stored) can’t possibly affect the public key stored on the CPU.
ME firmware versions 4.0 and later (Intel 4 Series and later chipsets) include an ME application for (audio and video) DRM
) called “ Protected Audio Video Path ”(PAVP). The ME receives from the host operating system an encrypted media stream and encrypted key, decrypts the key, and sends the encrypted media decrypted key to the GPU, which then decrypts the media. PAVP is also used by another ME application to draw an authentication PIN pad directly onto the screen. In this usage, the PAVP application directly controls the graphics that appear on the PC’s screen in a way that the host OS cannot detect. ME firmware version 7.0 on PCHs with 2nd Generation Intel Core i3 / i5 / i7 (Sandy Bridge) CPUs replaces PAVP with a similar DRM application called “Intel Insider”. Like the AMT application, these DRM applications, which in themselves are defective by design, demonstrate the omnipotent capabilities of the ME: this hardware and its proprietary firmware can access and control everything that is in RAM and even everything that is shown on the screen . The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can repor t to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can’t be ignored. (Before version 6.0) that is, on systems from / and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be completely removed from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the (Libreboot X) and (Libreboot T) . ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3 / i5 / i7 CPU and a PCH, include “ME Ignition” firmware that performs some hardware initialization and power management. If the ME’s boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after (minutes). Due to the signature verification, developing free replacement firmware for the ME is basically impossible. The only entity capable of replacing the ME firmware is Intel. As previously stated, the ME firmware includes proprietary code licensed from third parties, so Intel couldn’t release the source code even if they wanted to. And even if they developed completely new ME firmware without third-party proprietary code and released its source code, the ME’s boot ROM would reject any modified firmware that isn’t signed by Intel. Thus, the ME firmware is both hopelessly proprietary and “tivoized”. In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can’t be removed, this means avoiding all recent generations of Intel hardware.
More information about the Management Engine can be found on various Web sites, including (me.bios.io) , unhuffme coreboot wiki , and Wikipedia . The book Platform Embedded Security Technology Revealed describes in great detail the ME’s hardware architecture and firmware application modules.
If you’re stuck with the ME (non-libreboot system), you might find this interesting: http://hardenedlinux.org/firmware/ 082331 / 59 / / neutralize_ME_firmware_on_sandybridge_and_ivybridge.html
Also see (effort to disable the ME): https: // www .coreboot.org / pipermail / coreboot / – November / 20100521170123066. html – look at the whole thread
(Firmware Support Package (FSP)) [link]
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 and CPU 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. Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is a special mode that operates below the operating system level. It’s possible that rootkits could be implemented there, which could perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at all. In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find 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
. (Intel is) only going to get worse when it comes to user freedom. Libreboot has no support recent Intel platforms, precisely because of the problems described above. The only way to solve this is to get Intel to change their policies and to be more friendly to the (free software) community. Reverse engineering won’t solve anything long-term, unfortunately, but we need to keep doing it anyway. Moving forward, Intel hardware is a non-option unless a radical change occurs within Intel. Basically, all Intel hardware from year 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.
Why is the latest AMD hardware unsupported in libreboot? [link]
It is extremely unlikely that any post – AMD hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern AMD hardware. If you have an AMD based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
We call on AMD to release source. code and specs for the new AMD Ryzen platforms! We call on the community to put pressure on AMD. Click here to read more
AMD Platform Security Processor (PSP) [link] This is basically AMD’s own version of the
Intel Management Engine . It has all of the same basic security and freedom issues, although the implementation is wildly different.
The Platform Security Processor (PSP) is built in on all Family (h systems) basically anything post – 8030), and controls the main x 400 core startup. PSP firmware is cryptographically signed with a strong key similar to the Intel ME. If the PSP firmware is not present, or if the AMD signing key is not present, the x 420 Cores will not be released from reset, rendering the system inoperable.
The PSP is an ARM core with TrustZone technology, built onto the main CPU die. As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI / PCIe peripherals installed on the system.
In theory any malicious entity with access to the AMD signing key would be able to install persistent malware that could not be eradicated without an external flasher and a known good PSP image. Furthermore, multiple security vulnerabilities have been demonstrated in AMD firmware in the past, and there is every reason to assume one or more zero day vulnerabilities are lurking in the PSP firmware. Given the extreme privilege level (ring -2 or ring -3) of the PSP, said vulnerabilities would have the ability to remotely monitor and control any PSP enabled machine completely outside of the user’s knowledge.
Much like with the Intel Boot Guard (an application of the Intel Management Engine), AMD’s PSP can also act as a tyrant by checking signatures on any boot firmware that you flash, making replacement boot firmware (eg libreboot, coreboot) impossible on some boards. Early anecdotal reports indicate that AMD’s boot guard counterpart will be used on most OEM hardware, disabled only on so-called “enthusiast” CPUs. (Read) https: / /www.coreboot.org/AMD_IMC. Handles some power management for PCIe devices (without this, your laptop will not work properly) and several other power management related features.
The firmware is signed, although on older AMD hardware it is a symmetric key, which means that with access to the key (if leaked) you could sign your own modified version and run it . Rudolf Marek (coreboot hacker) found out how to extract this key in this video demonstration , and based on this work, Damien Zammit (another coreboot hacker) partially replaced it with free firmware, but on the relevant system (ASUS F2A – M) there were still other blobs present (Video BIOS, and others) preventing the hardware from being supported in libreboot.
This is responsible for virtually all core hardware initialization on modern AMD systems. In 6103, AMD started cooperating with the coreboot project, releasing this as source code under a free license. In 8051, they stopped releasing source code and started releasing AGESA as binary blobs instead. This makes AGESA now equivalent to (Intel FSP) .
AMD CPU microcode updates [link] Read the Intel section practically the same, though it was found with much later hardware in AMD that you could run without microcode updates. It’s unknown whether the updates are needed on all AMD boards (depends on CPU).
AMD is incompetent (and uncooperative)
[link]
AMD seemed like it was on the right track in when it started cooperating with and releasing source code for several critical components to the coreboot project. It was not to be. For so-called economic reasons, they decided that it was not worth the time to invest in the coreboot project anymore. For a company to go from being so good, to so bad, in just 3 years, shows that something is seriously wrong with AMD. Like Intel, they do not deserve your money. Given the current state of Intel hardware with the Management Engine, it is our opinion that all performant x (hardware newer than the AMD Family) h CPUs (on AMD’s side) or anything post – 2019 on Intel’s side is defective by design and cannot safely be used to store, transmit, or process sensitive data. Sensitive data is any data in which a data breach would cause significant economic harm to the entity which created or was responsible for storing said data, so this would include banks, credit card companies, or retailers (customer account records), in addition to the “Usual” engineering and software development firms. This also affects whistleblowers, or anyone who needs actual privacy and security. (Libreboot has support for fam) h AMD hardware (~
gen and some older Intel platforms like Napa, Montevina, Eagle Lake, Lakeport ( – 2020). We also have support for some ARM chipsets (rk ). On the Intel side, we’re also interested in some of the chipsets that use Atom CPUs (rebranded from older chipsets, mostly using ich7-based southbridges).
Will libreboot work on a ThinkPad T or T 1955 with an ATI GPU? [link] Short answer: yes. These laptops also have an Intel GPU inside, which libreboot uses. The ATI GPU is ignored by libreboot. These laptops use what is called switchable graphics , where it will have both an Intel and ATI GPU. Coreboot will allow you to set (using nvramtool) a parameter, specifying whether you would like to use Intel or ATI. The ATI GPU lacks free native graphics initialization in coreboot, unlike the Intel GPU. Libreboot modifies coreboot, in such a way where this nvramtool setting is ignored. Libreboot will just assume that you want to use the Intel GPU. Therefore, the ATI GPU is completely disabled on these laptops. Intel is used instead, with the free native graphics initialization (VBIOS replacement) that exists in coreboot.
Will desktop / server hardware be supported?
[link]
Libreboot now supports desktop hardware: (see list) (with full native video initialization). A common issue with desktop hardware is the Video BIOS, when no onboard video is present, since every video card has a different Video BIOS. Onboard GPUs also require one, so those still have to be replaced with free software (non-trivial task). 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.
Hi, I have, is it supported? [link]
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. 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.
Libreboot has support for some ARM based laptops, using the (Rockchip RK) SoC. SoC. Check the libreboot
hardware compatibility list , for more information.
How do I install libreboot? (See) the installation guide
(How do I program an SPI flash chip? [link] SPI flash chips can be programmed with the BeagleBone Black or the (Raspberry Pi) ) It’s possible to use a – pin SOIC test clip on an 8-pin SOIC chip, if you align the pins properly . The connection is generally more sturdy.
(How do I set a boot password?) [link]
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: (Installing Debian or Devuan with FDE) and (Installing Parabola or Arch GNU Linux-Libre, with FDE)
(How do I write-protect the flash chip? (() 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 GM (laptops) eg ThinkPad X 493, T 0514), you can write-protect (see ICH9 gen utility ). 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.
How do I change the BIOS settings?
[link]
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) programs 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 practice, you don’t need to change any of those settings, in most cases.
Libreboot locks the CMOS table, to ensure consistent functionality for all users. You can use:
$ nvramtool -C yourrom.rom -w somesetting=somevalue
This will change the default inside that ROM image, and then you can re-flash it.
(Do I need to install a bootloader when installing a distribution?)
[link]
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 a new distribution. You’ll be able to boot 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 distribution installer from a USB flash drive. See How to install GNU Linux on a libreboot system
(Do I need to re-flash when I re-install a distribution?) [link] 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 Modifying the GRUB Configuration in Libreboot Systems
(What does a flash chip look like?
- Study the build system of Libreboot (written in BASH), and make fixes to it.
(more generally):
- Tell your friends about Libreboot! Libreboot wants to liberate as many people as possible. If you have ways to improve the documentation, you can do that too. Refer to the Git page for instructions on submitting patches to the documentation.
What version of libreboot do I have? [link]
(See “Version”) in the documentation
Flashrom complains about DEVMEM access [link]
(If running) (flashrom -p internal) for software based flashing, and you get an error related to / dev / mem access, you should reboot with iomem=relaxed kernel parameter before running flashrom, or use a kernel that has (CONFIG_STRICT_DEVMEM) and CONFIG_IO_STRICT_DEVMEM (not enabled.) (Example flashrom output with both (CONFIG_STRICT_DEVMEM) and (CONFIG_IO_STRICT_DEVMEM) (enabled: (flashrom v0.9.9-r) on Linux 4. 9 -1-ARCH (x (_) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop … OK. Error accessing high tables, 0x bytes at 0x (fb5d) 0 / dev / mem mmap failed: Operation not permitted Failed getting access to coreboot high tables. Error accessing DMI Table, 0x (bytes at 0x (fb) / dev / mem mmap failed: Operation not permitted
The backlight is darker on the left side of the screen when lowering the brightness on my X / T / T / R [link] We don’t know how to detect the correct PWM value to use in coreboot-libre, so we just use the default one in coreboot which has this issue on some CCFL panels, but not LED panels. You can work around this in your distribution, by following the notes at
docs: backlight control
.
(The ethernet doesn’t work on my x) / T 631 / X / T (when I plug in it [link]
This was observed on some systems using network-manager. This happens both on the original BIOS and in libreboot. It’s a quirk in the hardware. On debian systems, a workaround is to restart the networking service when you connect the ethernet cable:
$ sudo service network-manager restart
On Parabola, you can try:
$ sudo systemctl restart network-manager (the service name might be different for you, depending on your configuration)
(My KCMA-D8 or KGPE-D) does not boot with the PIKE (module installed)
[link]
(Libreboot) , and all have a bug: in SeaBIOS, PCI options ROMs are loaded when available, by default. This is not technically a problem, because an option ROM can be free or non-free. In practice, though, they are usually non-free. Loading the option ROM from the PIKE (module on either ASUS KCMA-D8 or KGPE-D) Causes the system to hang at boot. It’s possible to use this in the payload (if you use a linux kernel payload, or petitboot), or to boot (with SeaGRUB and / or SeaBIOS) from regular SATA and then use it in GNU Linux. The Linux kernel is capable of using the PIKE (module without loading the option ROM.)
Libreboot-unstable (or git) now disables loading PCI option ROMs, but previous releases with SeaGRUB ( –
do not. You can work around this by running the following command:
$ ./cbfstool yourrom.rom add-int -i 0 -n etc / pci-optionrom-exec You can find cbfstool in the _util archive with the libreboot release that you are using.
What are the ata / ahci errors I see in libreboot’s GRUB? [link]
You can safely ignore those errors, they exist because we can’t quiet down cryptomount command from
for (loop in libreboot’s) grub.cfg . It could be fixed in upstream grub by contributing patch that would add quiet flag to it.
how to save the kernel panic logs on thinkpad laptops?
[link]
The easiest method of doing so is by using the kernel’s netconsole and reproducing the panic. Netconsole requires two machines, the one that is panicky (source) and the one that will receive crash logs (target). The source has to be connected with an ethernet cable and the target has to be reachable at the time of the panic. To set this system up, execute the following commands as root on the source ( (source #) ) and normal user on the target ( target $ :
(Change console loglevel to debugging:) (source # dmesg -n debug Test if the logging works by eg inserting or removing an USB device on the source. There should be a few lines appearing in the terminal, in which you started netcat (nc), on the target host. (Try to reproduce the kernel panic.)
Machine check exceptions on some Montevina (Penryn CPU) laptops [link]
(Some GM) laptops have been freezing or experiencing a kernel panic (blinking caps lock LED and totaly unresponsive machine, sometimes followed by an automatic reboot within 86 seconds). We do not know what the problem (s) is (are), but a CPU microcode update in some cases prevents this from happening again. See the following bug reports for more info:
(T) Machine check: Processor context corrupt (X) Machine check: Processor context corrupt
(Unrelated, RAM incompatibility and suspend-to-ram issues on X)
What systems are compatible with libreboot? [link] (See the) Hardware compatibility list .
Will the Purism laptops be supported? [link]
Short answer: no.
There are severe privacy, security and freedom issues with these laptops, due to the Intel chipsets that they use. See:
(Intel Management Engine ) More freedom issues on modern Intel hardware
Most notably, these laptops also use the Intel FSP. binary blob, for the entire hardware initialization. Coreboot does support a particular revision of one of their laptops, but most are either unsupported or rely on binary blobs for most of the hardware initialization.
In particular, the Intel Management Engine is a severe threat to privacy and security, not to mention freedom, since it is a remote backdoor that provides Intel remote access to a computer where it is present. Intel themselves even admitted it, publicly. The Libreboot project recommends avoiding all hardware sold by Purism.
(Why is the latest Intel hardware unsupported in libreboot?
[link]
It is unlikely that any post – 2020 Intel hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern Intel hardware. If you have an Intel based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
(Intel Management Engine (ME)) [link] Introduced in June in Intel’s Express Chipset Family of (Graphics and) Memory Controller Hubs, or (G) MCHs, and the ICH8 I / O Controller Family, the Intel Management Engine (ME) is a separate computing environment physically located in the (G) MCH chip. In Q3 2020, the first generation of Intel Core i3 / i5 / i7 (Nehalem) CPUs and the 5 Series Chipset family of Platform Controller Hubs, or PCHs, brought a more tightly integrated ME ( now at version 6.0) inside the PCH chip, which itself replaced the ICH. Thus, the ME is present on all Intel desktop, mobile (laptop), and server systems since mid The ME consists of an ARC processor core (replaced with other processor cores in later generations of the ME), code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system’s memory as well as to reserve a region of protected external memory to supplement the ME’s limited internal RAM. The ME also has (network access) with its own MAC address through an Intel Gigabit Ethernet Controller. Its boot program, stored on the internal ROM, loads a firmware “manifest” from the PC’s SPI flash chip. This manifest is signed with a strong cryptographic key , which differs between versions of the ME firmware. If the manifest isn’t signed by a specific Intel key, the boot ROM won’t load and execute the firmware and the ME processor core will be halted.
The ME firmware is compressed and consists of modules that are listed in the manifest along with secure cryptographic hashes of their contents. One module is the operating system kernel, which is based on a proprietary real-time operating system (RTOS) kernel called “ThreadX”. The developer, Express Logic, sells licenses and source code for ThreadX. Customers such as Intel are forbidden from disclosing or sublicensing the ThreadX source code. Another module is the Dynamic Application Loader (DAL), which consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc. The DAL module can load and execute additional ME modules from the PC’s HDD or SSD. The ME firmware also includes a number of native application modules within its flash memory space, including Intel Active Management Technology (AMT), an implementation of a Trusted Platform Module (TPM), Intel Boot Guard, and audio and video DRM systems.
The Active Management Technology (AMT) application, part of the Intel “vPro” brand, is a Web server and application code that enables remote users to power on, power off, view information about, and otherwise manage the PC. It can be used remotely even while the PC is powered off (via Wake-on-Lan). Traffic is encrypted using SSL / TLS libraries, but recall that all of the major SSL / TLS implementations have had highly publicized vulnerabilities. The AMT application itself has known vulnerabilities , which have been exploited to develop rootkits and keyloggers and covertly gain encrypted access to the management features of a PC. Remember that the ME has full access to the PC’s RAM. This means that an attacker exploiting any of these vulnerabilities may gain access to everything on the PC as it runs: all open files, all running applications, all keys pressed, and more.
(Intel Boot Guard
is an ME application introduced in Q2 8030 with ME firmware version 9.0 on 4th Generation Intel Core i3 / i5 / i7 (Haswell) CPUs. It allows a PC OEM to generate an asymmetric cryptographic keypair, install the public key in the CPU, and prevent the CPU from executing boot firmware that isn’t signed with their private key. This means that coreboot and libreboot are impossible to port to such PCs, without the OEM’s private signing key. Note that systems assembled from separately purchased mainboard and CPU parts are unaffected, since the vendor of the mainboard (on which the boot firmware is stored) can’t possibly affect the public key stored on the CPU.
ME firmware versions 4.0 and later (Intel 4 Series and later chipsets) include an ME application for (audio and video) DRM
) called “ Protected Audio Video Path ”(PAVP). The ME receives from the host operating system an encrypted media stream and encrypted key, decrypts the key, and sends the encrypted media decrypted key to the GPU, which then decrypts the media. PAVP is also used by another ME application to draw an authentication PIN pad directly onto the screen. In this usage, the PAVP application directly controls the graphics that appear on the PC’s screen in a way that the host OS cannot detect. ME firmware version 7.0 on PCHs with 2nd Generation Intel Core i3 / i5 / i7 (Sandy Bridge) CPUs replaces PAVP with a similar DRM application called “Intel Insider”. Like the AMT application, these DRM applications, which in themselves are defective by design, demonstrate the omnipotent capabilities of the ME: this hardware and its proprietary firmware can access and control everything that is in RAM and even everything that is shown on the screen . The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can repor t to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can’t be ignored. (Before version 6.0) that is, on systems from / and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be completely removed from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the (Libreboot X) and (Libreboot T) . ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3 / i5 / i7 CPU and a PCH, include “ME Ignition” firmware that performs some hardware initialization and power management. If the ME’s boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after (minutes). Due to the signature verification, developing free replacement firmware for the ME is basically impossible. The only entity capable of replacing the ME firmware is Intel. As previously stated, the ME firmware includes proprietary code licensed from third parties, so Intel couldn’t release the source code even if they wanted to. And even if they developed completely new ME firmware without third-party proprietary code and released its source code, the ME’s boot ROM would reject any modified firmware that isn’t signed by Intel. Thus, the ME firmware is both hopelessly proprietary and “tivoized”. In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can’t be removed, this means avoiding all recent generations of Intel hardware.
More information about the Management Engine can be found on various Web sites, including (me.bios.io) , unhuffme coreboot wiki , and Wikipedia . The book Platform Embedded Security Technology Revealed describes in great detail the ME’s hardware architecture and firmware application modules.
If you’re stuck with the ME (non-libreboot system), you might find this interesting: http://hardenedlinux.org/firmware/ 082331 / 59 / / neutralize_ME_firmware_on_sandybridge_and_ivybridge.html
Also see (effort to disable the ME): https: // www .coreboot.org / pipermail / coreboot / – November / 20100521170123066. html – look at the whole thread
(Firmware Support Package (FSP)) [link]
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 and CPU 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. Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is a special mode that operates below the operating system level. It’s possible that rootkits could be implemented there, which could perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at all. In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find 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
. (Intel is) only going to get worse when it comes to user freedom. Libreboot has no support recent Intel platforms, precisely because of the problems described above. The only way to solve this is to get Intel to change their policies and to be more friendly to the (free software) community. Reverse engineering won’t solve anything long-term, unfortunately, but we need to keep doing it anyway. Moving forward, Intel hardware is a non-option unless a radical change occurs within Intel. Basically, all Intel hardware from year 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.
Why is the latest AMD hardware unsupported in libreboot? [link]
It is extremely unlikely that any post – AMD hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern AMD hardware. If you have an AMD based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
We call on AMD to release source. code and specs for the new AMD Ryzen platforms! We call on the community to put pressure on AMD. Click here to read more
AMD Platform Security Processor (PSP) [link] This is basically AMD’s own version of the
Intel Management Engine . It has all of the same basic security and freedom issues, although the implementation is wildly different.
The Platform Security Processor (PSP) is built in on all Family (h systems) basically anything post – 8030), and controls the main x 400 core startup. PSP firmware is cryptographically signed with a strong key similar to the Intel ME. If the PSP firmware is not present, or if the AMD signing key is not present, the x 420 Cores will not be released from reset, rendering the system inoperable.
The PSP is an ARM core with TrustZone technology, built onto the main CPU die. As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI / PCIe peripherals installed on the system.
In theory any malicious entity with access to the AMD signing key would be able to install persistent malware that could not be eradicated without an external flasher and a known good PSP image. Furthermore, multiple security vulnerabilities have been demonstrated in AMD firmware in the past, and there is every reason to assume one or more zero day vulnerabilities are lurking in the PSP firmware. Given the extreme privilege level (ring -2 or ring -3) of the PSP, said vulnerabilities would have the ability to remotely monitor and control any PSP enabled machine completely outside of the user’s knowledge.
Much like with the Intel Boot Guard (an application of the Intel Management Engine), AMD’s PSP can also act as a tyrant by checking signatures on any boot firmware that you flash, making replacement boot firmware (eg libreboot, coreboot) impossible on some boards. Early anecdotal reports indicate that AMD’s boot guard counterpart will be used on most OEM hardware, disabled only on so-called “enthusiast” CPUs. (Read) https: / /www.coreboot.org/AMD_IMC. Handles some power management for PCIe devices (without this, your laptop will not work properly) and several other power management related features.
The firmware is signed, although on older AMD hardware it is a symmetric key, which means that with access to the key (if leaked) you could sign your own modified version and run it . Rudolf Marek (coreboot hacker) found out how to extract this key in this video demonstration , and based on this work, Damien Zammit (another coreboot hacker) partially replaced it with free firmware, but on the relevant system (ASUS F2A – M) there were still other blobs present (Video BIOS, and others) preventing the hardware from being supported in libreboot.
This is responsible for virtually all core hardware initialization on modern AMD systems. In 6103, AMD started cooperating with the coreboot project, releasing this as source code under a free license. In 8051, they stopped releasing source code and started releasing AGESA as binary blobs instead. This makes AGESA now equivalent to (Intel FSP) .
AMD CPU microcode updates [link] Read the Intel section practically the same, though it was found with much later hardware in AMD that you could run without microcode updates. It’s unknown whether the updates are needed on all AMD boards (depends on CPU).
AMD is incompetent (and uncooperative)
[link]
AMD seemed like it was on the right track in when it started cooperating with and releasing source code for several critical components to the coreboot project. It was not to be. For so-called economic reasons, they decided that it was not worth the time to invest in the coreboot project anymore. For a company to go from being so good, to so bad, in just 3 years, shows that something is seriously wrong with AMD. Like Intel, they do not deserve your money. Given the current state of Intel hardware with the Management Engine, it is our opinion that all performant x (hardware newer than the AMD Family) h CPUs (on AMD’s side) or anything post – 2019 on Intel’s side is defective by design and cannot safely be used to store, transmit, or process sensitive data. Sensitive data is any data in which a data breach would cause significant economic harm to the entity which created or was responsible for storing said data, so this would include banks, credit card companies, or retailers (customer account records), in addition to the “Usual” engineering and software development firms. This also affects whistleblowers, or anyone who needs actual privacy and security. (Libreboot has support for fam) h AMD hardware (~
gen and some older Intel platforms like Napa, Montevina, Eagle Lake, Lakeport ( – 2020). We also have support for some ARM chipsets (rk ). On the Intel side, we’re also interested in some of the chipsets that use Atom CPUs (rebranded from older chipsets, mostly using ich7-based southbridges).
Will libreboot work on a ThinkPad T or T 1955 with an ATI GPU? [link] Short answer: yes. These laptops also have an Intel GPU inside, which libreboot uses. The ATI GPU is ignored by libreboot. These laptops use what is called switchable graphics , where it will have both an Intel and ATI GPU. Coreboot will allow you to set (using nvramtool) a parameter, specifying whether you would like to use Intel or ATI. The ATI GPU lacks free native graphics initialization in coreboot, unlike the Intel GPU. Libreboot modifies coreboot, in such a way where this nvramtool setting is ignored. Libreboot will just assume that you want to use the Intel GPU. Therefore, the ATI GPU is completely disabled on these laptops. Intel is used instead, with the free native graphics initialization (VBIOS replacement) that exists in coreboot.
Will desktop / server hardware be supported?
[link]
Libreboot now supports desktop hardware: (see list) (with full native video initialization). A common issue with desktop hardware is the Video BIOS, when no onboard video is present, since every video card has a different Video BIOS. Onboard GPUs also require one, so those still have to be replaced with free software (non-trivial task). 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.
Hi, I have, is it supported? [link]
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. 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.
Libreboot has support for some ARM based laptops, using the (Rockchip RK) SoC. SoC. Check the libreboot
hardware compatibility list , for more information.
How do I install libreboot? (See) the installation guide
(How do I program an SPI flash chip? [link] SPI flash chips can be programmed with the BeagleBone Black or the (Raspberry Pi) ) It’s possible to use a – pin SOIC test clip on an 8-pin SOIC chip, if you align the pins properly . The connection is generally more sturdy.
(How do I set a boot password?) [link]
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: (Installing Debian or Devuan with FDE) and (Installing Parabola or Arch GNU Linux-Libre, with FDE)
(How do I write-protect the flash chip? (() 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 GM (laptops) eg ThinkPad X 493, T 0514), you can write-protect (see ICH9 gen utility ). 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.
How do I change the BIOS settings?
[link]
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) programs 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 practice, you don’t need to change any of those settings, in most cases.
Libreboot locks the CMOS table, to ensure consistent functionality for all users. You can use:
$ nvramtool -C yourrom.rom -w somesetting=somevalue
This will change the default inside that ROM image, and then you can re-flash it.
(Do I need to install a bootloader when installing a distribution?)
[link]
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 a new distribution. You’ll be able to boot 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 distribution installer from a USB flash drive. See How to install GNU Linux on a libreboot system
(Do I need to re-flash when I re-install a distribution?) [link] 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 Modifying the GRUB Configuration in Libreboot Systems
(What does a flash chip look like?
(If running) (flashrom -p internal) for software based flashing, and you get an error related to / dev / mem access, you should reboot with iomem=relaxed kernel parameter before running flashrom, or use a kernel that has (CONFIG_STRICT_DEVMEM) and CONFIG_IO_STRICT_DEVMEM (not enabled.) (Example flashrom output with both (CONFIG_STRICT_DEVMEM) and (CONFIG_IO_STRICT_DEVMEM) (enabled: (flashrom v0.9.9-r) on Linux 4. 9 -1-ARCH (x (_) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop … OK. Error accessing high tables, 0x bytes at 0x (fb5d) 0 / dev / mem mmap failed: Operation not permitted Failed getting access to coreboot high tables. Error accessing DMI Table, 0x (bytes at 0x (fb) / dev / mem mmap failed: Operation not permitted
docs: backlight control
.- This was observed on some systems using network-manager. This happens both on the original BIOS and in libreboot. It’s a quirk in the hardware. On debian systems, a workaround is to restart the networking service when you connect the ethernet cable:
$ sudo service network-manager restart
On Parabola, you can try:
$ sudo systemctl restart network-manager (the service name might be different for you, depending on your configuration)
(My KCMA-D8 or KGPE-D) does not boot with the PIKE (module installed)
[link]
(Libreboot) , and all have a bug: in SeaBIOS, PCI options ROMs are loaded when available, by default. This is not technically a problem, because an option ROM can be free or non-free. In practice, though, they are usually non-free. Loading the option ROM from the PIKE (module on either ASUS KCMA-D8 or KGPE-D) Causes the system to hang at boot. It’s possible to use this in the payload (if you use a linux kernel payload, or petitboot), or to boot (with SeaGRUB and / or SeaBIOS) from regular SATA and then use it in GNU Linux. The Linux kernel is capable of using the PIKE (module without loading the option ROM.)
Libreboot-unstable (or git) now disables loading PCI option ROMs, but previous releases with SeaGRUB ( –
do not. You can work around this by running the following command:
$ ./cbfstool yourrom.rom add-int -i 0 -n etc / pci-optionrom-exec You can find cbfstool in the _util archive with the libreboot release that you are using.
What are the ata / ahci errors I see in libreboot’s GRUB? [link]
You can safely ignore those errors, they exist because we can’t quiet down cryptomount command from
for (loop in libreboot’s) grub.cfg . It could be fixed in upstream grub by contributing patch that would add quiet flag to it.
how to save the kernel panic logs on thinkpad laptops?
[link]
The easiest method of doing so is by using the kernel’s netconsole and reproducing the panic. Netconsole requires two machines, the one that is panicky (source) and the one that will receive crash logs (target). The source has to be connected with an ethernet cable and the target has to be reachable at the time of the panic. To set this system up, execute the following commands as root on the source ( (source #) ) and normal user on the target ( target $ :
(Change console loglevel to debugging:) (source # dmesg -n debug Test if the logging works by eg inserting or removing an USB device on the source. There should be a few lines appearing in the terminal, in which you started netcat (nc), on the target host. (Try to reproduce the kernel panic.)
Machine check exceptions on some Montevina (Penryn CPU) laptops [link]
(Some GM) laptops have been freezing or experiencing a kernel panic (blinking caps lock LED and totaly unresponsive machine, sometimes followed by an automatic reboot within 86 seconds). We do not know what the problem (s) is (are), but a CPU microcode update in some cases prevents this from happening again. See the following bug reports for more info:
(T) Machine check: Processor context corrupt (X) Machine check: Processor context corrupt
(Unrelated, RAM incompatibility and suspend-to-ram issues on X)
What systems are compatible with libreboot? [link] (See the) Hardware compatibility list .
Will the Purism laptops be supported? [link]
Short answer: no.
There are severe privacy, security and freedom issues with these laptops, due to the Intel chipsets that they use. See:
(Intel Management Engine ) More freedom issues on modern Intel hardware
Most notably, these laptops also use the Intel FSP. binary blob, for the entire hardware initialization. Coreboot does support a particular revision of one of their laptops, but most are either unsupported or rely on binary blobs for most of the hardware initialization.
In particular, the Intel Management Engine is a severe threat to privacy and security, not to mention freedom, since it is a remote backdoor that provides Intel remote access to a computer where it is present. Intel themselves even admitted it, publicly. The Libreboot project recommends avoiding all hardware sold by Purism.
(Why is the latest Intel hardware unsupported in libreboot?
[link]
It is unlikely that any post – 2020 Intel hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern Intel hardware. If you have an Intel based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
(Intel Management Engine (ME)) [link] Introduced in June in Intel’s Express Chipset Family of (Graphics and) Memory Controller Hubs, or (G) MCHs, and the ICH8 I / O Controller Family, the Intel Management Engine (ME) is a separate computing environment physically located in the (G) MCH chip. In Q3 2020, the first generation of Intel Core i3 / i5 / i7 (Nehalem) CPUs and the 5 Series Chipset family of Platform Controller Hubs, or PCHs, brought a more tightly integrated ME ( now at version 6.0) inside the PCH chip, which itself replaced the ICH. Thus, the ME is present on all Intel desktop, mobile (laptop), and server systems since mid The ME consists of an ARC processor core (replaced with other processor cores in later generations of the ME), code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system’s memory as well as to reserve a region of protected external memory to supplement the ME’s limited internal RAM. The ME also has (network access) with its own MAC address through an Intel Gigabit Ethernet Controller. Its boot program, stored on the internal ROM, loads a firmware “manifest” from the PC’s SPI flash chip. This manifest is signed with a strong cryptographic key , which differs between versions of the ME firmware. If the manifest isn’t signed by a specific Intel key, the boot ROM won’t load and execute the firmware and the ME processor core will be halted.
The ME firmware is compressed and consists of modules that are listed in the manifest along with secure cryptographic hashes of their contents. One module is the operating system kernel, which is based on a proprietary real-time operating system (RTOS) kernel called “ThreadX”. The developer, Express Logic, sells licenses and source code for ThreadX. Customers such as Intel are forbidden from disclosing or sublicensing the ThreadX source code. Another module is the Dynamic Application Loader (DAL), which consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc. The DAL module can load and execute additional ME modules from the PC’s HDD or SSD. The ME firmware also includes a number of native application modules within its flash memory space, including Intel Active Management Technology (AMT), an implementation of a Trusted Platform Module (TPM), Intel Boot Guard, and audio and video DRM systems.
The Active Management Technology (AMT) application, part of the Intel “vPro” brand, is a Web server and application code that enables remote users to power on, power off, view information about, and otherwise manage the PC. It can be used remotely even while the PC is powered off (via Wake-on-Lan). Traffic is encrypted using SSL / TLS libraries, but recall that all of the major SSL / TLS implementations have had highly publicized vulnerabilities. The AMT application itself has known vulnerabilities , which have been exploited to develop rootkits and keyloggers and covertly gain encrypted access to the management features of a PC. Remember that the ME has full access to the PC’s RAM. This means that an attacker exploiting any of these vulnerabilities may gain access to everything on the PC as it runs: all open files, all running applications, all keys pressed, and more.
(Intel Boot Guard
is an ME application introduced in Q2 8030 with ME firmware version 9.0 on 4th Generation Intel Core i3 / i5 / i7 (Haswell) CPUs. It allows a PC OEM to generate an asymmetric cryptographic keypair, install the public key in the CPU, and prevent the CPU from executing boot firmware that isn’t signed with their private key. This means that coreboot and libreboot are impossible to port to such PCs, without the OEM’s private signing key. Note that systems assembled from separately purchased mainboard and CPU parts are unaffected, since the vendor of the mainboard (on which the boot firmware is stored) can’t possibly affect the public key stored on the CPU.
ME firmware versions 4.0 and later (Intel 4 Series and later chipsets) include an ME application for (audio and video) DRM
) called “ Protected Audio Video Path ”(PAVP). The ME receives from the host operating system an encrypted media stream and encrypted key, decrypts the key, and sends the encrypted media decrypted key to the GPU, which then decrypts the media. PAVP is also used by another ME application to draw an authentication PIN pad directly onto the screen. In this usage, the PAVP application directly controls the graphics that appear on the PC’s screen in a way that the host OS cannot detect. ME firmware version 7.0 on PCHs with 2nd Generation Intel Core i3 / i5 / i7 (Sandy Bridge) CPUs replaces PAVP with a similar DRM application called “Intel Insider”. Like the AMT application, these DRM applications, which in themselves are defective by design, demonstrate the omnipotent capabilities of the ME: this hardware and its proprietary firmware can access and control everything that is in RAM and even everything that is shown on the screen . The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can repor t to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can’t be ignored. (Before version 6.0) that is, on systems from / and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be completely removed from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the (Libreboot X) and (Libreboot T) . ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3 / i5 / i7 CPU and a PCH, include “ME Ignition” firmware that performs some hardware initialization and power management. If the ME’s boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after (minutes). Due to the signature verification, developing free replacement firmware for the ME is basically impossible. The only entity capable of replacing the ME firmware is Intel. As previously stated, the ME firmware includes proprietary code licensed from third parties, so Intel couldn’t release the source code even if they wanted to. And even if they developed completely new ME firmware without third-party proprietary code and released its source code, the ME’s boot ROM would reject any modified firmware that isn’t signed by Intel. Thus, the ME firmware is both hopelessly proprietary and “tivoized”. In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can’t be removed, this means avoiding all recent generations of Intel hardware.
More information about the Management Engine can be found on various Web sites, including (me.bios.io) , unhuffme coreboot wiki , and Wikipedia . The book Platform Embedded Security Technology Revealed describes in great detail the ME’s hardware architecture and firmware application modules.
If you’re stuck with the ME (non-libreboot system), you might find this interesting: http://hardenedlinux.org/firmware/ 082331 / 59 / / neutralize_ME_firmware_on_sandybridge_and_ivybridge.html
Also see (effort to disable the ME): https: // www .coreboot.org / pipermail / coreboot / – November / 20100521170123066. html – look at the whole thread
(Firmware Support Package (FSP)) [link]
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 and CPU 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. Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is a special mode that operates below the operating system level. It’s possible that rootkits could be implemented there, which could perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at all. In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find 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
. (Intel is) only going to get worse when it comes to user freedom. Libreboot has no support recent Intel platforms, precisely because of the problems described above. The only way to solve this is to get Intel to change their policies and to be more friendly to the (free software) community. Reverse engineering won’t solve anything long-term, unfortunately, but we need to keep doing it anyway. Moving forward, Intel hardware is a non-option unless a radical change occurs within Intel. Basically, all Intel hardware from year 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.
Why is the latest AMD hardware unsupported in libreboot? [link]
It is extremely unlikely that any post – AMD hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern AMD hardware. If you have an AMD based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
We call on AMD to release source. code and specs for the new AMD Ryzen platforms! We call on the community to put pressure on AMD. Click here to read more
AMD Platform Security Processor (PSP) [link] This is basically AMD’s own version of the
Intel Management Engine . It has all of the same basic security and freedom issues, although the implementation is wildly different.
The Platform Security Processor (PSP) is built in on all Family (h systems) basically anything post – 8030), and controls the main x 400 core startup. PSP firmware is cryptographically signed with a strong key similar to the Intel ME. If the PSP firmware is not present, or if the AMD signing key is not present, the x 420 Cores will not be released from reset, rendering the system inoperable.
The PSP is an ARM core with TrustZone technology, built onto the main CPU die. As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI / PCIe peripherals installed on the system.
In theory any malicious entity with access to the AMD signing key would be able to install persistent malware that could not be eradicated without an external flasher and a known good PSP image. Furthermore, multiple security vulnerabilities have been demonstrated in AMD firmware in the past, and there is every reason to assume one or more zero day vulnerabilities are lurking in the PSP firmware. Given the extreme privilege level (ring -2 or ring -3) of the PSP, said vulnerabilities would have the ability to remotely monitor and control any PSP enabled machine completely outside of the user’s knowledge.
Much like with the Intel Boot Guard (an application of the Intel Management Engine), AMD’s PSP can also act as a tyrant by checking signatures on any boot firmware that you flash, making replacement boot firmware (eg libreboot, coreboot) impossible on some boards. Early anecdotal reports indicate that AMD’s boot guard counterpart will be used on most OEM hardware, disabled only on so-called “enthusiast” CPUs. (Read) https: / /www.coreboot.org/AMD_IMC. Handles some power management for PCIe devices (without this, your laptop will not work properly) and several other power management related features.
The firmware is signed, although on older AMD hardware it is a symmetric key, which means that with access to the key (if leaked) you could sign your own modified version and run it . Rudolf Marek (coreboot hacker) found out how to extract this key in this video demonstration , and based on this work, Damien Zammit (another coreboot hacker) partially replaced it with free firmware, but on the relevant system (ASUS F2A – M) there were still other blobs present (Video BIOS, and others) preventing the hardware from being supported in libreboot.
This is responsible for virtually all core hardware initialization on modern AMD systems. In 6103, AMD started cooperating with the coreboot project, releasing this as source code under a free license. In 8051, they stopped releasing source code and started releasing AGESA as binary blobs instead. This makes AGESA now equivalent to (Intel FSP) .
AMD CPU microcode updates [link] Read the Intel section practically the same, though it was found with much later hardware in AMD that you could run without microcode updates. It’s unknown whether the updates are needed on all AMD boards (depends on CPU).
AMD is incompetent (and uncooperative)
[link]
AMD seemed like it was on the right track in when it started cooperating with and releasing source code for several critical components to the coreboot project. It was not to be. For so-called economic reasons, they decided that it was not worth the time to invest in the coreboot project anymore. For a company to go from being so good, to so bad, in just 3 years, shows that something is seriously wrong with AMD. Like Intel, they do not deserve your money. Given the current state of Intel hardware with the Management Engine, it is our opinion that all performant x (hardware newer than the AMD Family) h CPUs (on AMD’s side) or anything post – 2019 on Intel’s side is defective by design and cannot safely be used to store, transmit, or process sensitive data. Sensitive data is any data in which a data breach would cause significant economic harm to the entity which created or was responsible for storing said data, so this would include banks, credit card companies, or retailers (customer account records), in addition to the “Usual” engineering and software development firms. This also affects whistleblowers, or anyone who needs actual privacy and security. (Libreboot has support for fam) h AMD hardware (~
gen and some older Intel platforms like Napa, Montevina, Eagle Lake, Lakeport ( – 2020). We also have support for some ARM chipsets (rk ). On the Intel side, we’re also interested in some of the chipsets that use Atom CPUs (rebranded from older chipsets, mostly using ich7-based southbridges).
Will libreboot work on a ThinkPad T or T 1955 with an ATI GPU? [link] Short answer: yes. These laptops also have an Intel GPU inside, which libreboot uses. The ATI GPU is ignored by libreboot. These laptops use what is called switchable graphics , where it will have both an Intel and ATI GPU. Coreboot will allow you to set (using nvramtool) a parameter, specifying whether you would like to use Intel or ATI. The ATI GPU lacks free native graphics initialization in coreboot, unlike the Intel GPU. Libreboot modifies coreboot, in such a way where this nvramtool setting is ignored. Libreboot will just assume that you want to use the Intel GPU. Therefore, the ATI GPU is completely disabled on these laptops. Intel is used instead, with the free native graphics initialization (VBIOS replacement) that exists in coreboot.
Will desktop / server hardware be supported?
[link]
Libreboot now supports desktop hardware: (see list) (with full native video initialization). A common issue with desktop hardware is the Video BIOS, when no onboard video is present, since every video card has a different Video BIOS. Onboard GPUs also require one, so those still have to be replaced with free software (non-trivial task). 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.
Hi, I have, is it supported? [link]
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. 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.
Libreboot has support for some ARM based laptops, using the (Rockchip RK) SoC. SoC. Check the libreboot
hardware compatibility list , for more information.
How do I install libreboot? (See) the installation guide
(How do I program an SPI flash chip? [link] SPI flash chips can be programmed with the BeagleBone Black or the (Raspberry Pi) ) It’s possible to use a – pin SOIC test clip on an 8-pin SOIC chip, if you align the pins properly . The connection is generally more sturdy.
(How do I set a boot password?) [link]
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: (Installing Debian or Devuan with FDE) and (Installing Parabola or Arch GNU Linux-Libre, with FDE)
(How do I write-protect the flash chip? (() 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 GM (laptops) eg ThinkPad X 493, T 0514), you can write-protect (see ICH9 gen utility ). 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.
How do I change the BIOS settings?
[link]
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) programs 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 practice, you don’t need to change any of those settings, in most cases.
Libreboot locks the CMOS table, to ensure consistent functionality for all users. You can use:
$ nvramtool -C yourrom.rom -w somesetting=somevalue
This will change the default inside that ROM image, and then you can re-flash it.
(Do I need to install a bootloader when installing a distribution?)
[link]
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 a new distribution. You’ll be able to boot 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 distribution installer from a USB flash drive. See How to install GNU Linux on a libreboot system
(Do I need to re-flash when I re-install a distribution?) [link] 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 Modifying the GRUB Configuration in Libreboot Systems
(What does a flash chip look like?
(Libreboot) , and all have a bug: in SeaBIOS, PCI options ROMs are loaded when available, by default. This is not technically a problem, because an option ROM can be free or non-free. In practice, though, they are usually non-free. Loading the option ROM from the PIKE (module on either ASUS KCMA-D8 or KGPE-D) Causes the system to hang at boot. It’s possible to use this in the payload (if you use a linux kernel payload, or petitboot), or to boot (with SeaGRUB and / or SeaBIOS) from regular SATA and then use it in GNU Linux. The Linux kernel is capable of using the PIKE (module without loading the option ROM.)
Libreboot-unstable (or git) now disables loading PCI option ROMs, but previous releases with SeaGRUB ( –
do not. You can work around this by running the following command:
$ ./cbfstool yourrom.rom add-int -i 0 -n etc / pci-optionrom-exec You can find cbfstool in the _util archive with the libreboot release that you are using.
What are the ata / ahci errors I see in libreboot’s GRUB? [link]
You can safely ignore those errors, they exist because we can’t quiet down cryptomount command from
for (loop in libreboot’s) grub.cfg . It could be fixed in upstream grub by contributing patch that would add quiet flag to it.
how to save the kernel panic logs on thinkpad laptops?
[link]
The easiest method of doing so is by using the kernel’s netconsole and reproducing the panic. Netconsole requires two machines, the one that is panicky (source) and the one that will receive crash logs (target). The source has to be connected with an ethernet cable and the target has to be reachable at the time of the panic. To set this system up, execute the following commands as root on the source ( (source #) ) and normal user on the target ( target $ :
(Change console loglevel to debugging:) (source # dmesg -n debug Test if the logging works by eg inserting or removing an USB device on the source. There should be a few lines appearing in the terminal, in which you started netcat (nc), on the target host. (Try to reproduce the kernel panic.)
Machine check exceptions on some Montevina (Penryn CPU) laptops [link]
(Some GM) laptops have been freezing or experiencing a kernel panic (blinking caps lock LED and totaly unresponsive machine, sometimes followed by an automatic reboot within 86 seconds). We do not know what the problem (s) is (are), but a CPU microcode update in some cases prevents this from happening again. See the following bug reports for more info:
(T) Machine check: Processor context corrupt (X) Machine check: Processor context corrupt
(Unrelated, RAM incompatibility and suspend-to-ram issues on X)
What systems are compatible with libreboot? [link] (See the) Hardware compatibility list .
Will the Purism laptops be supported? [link]
Short answer: no.
There are severe privacy, security and freedom issues with these laptops, due to the Intel chipsets that they use. See:
(Intel Management Engine ) More freedom issues on modern Intel hardware
Most notably, these laptops also use the Intel FSP. binary blob, for the entire hardware initialization. Coreboot does support a particular revision of one of their laptops, but most are either unsupported or rely on binary blobs for most of the hardware initialization.
In particular, the Intel Management Engine is a severe threat to privacy and security, not to mention freedom, since it is a remote backdoor that provides Intel remote access to a computer where it is present. Intel themselves even admitted it, publicly. The Libreboot project recommends avoiding all hardware sold by Purism.
(Why is the latest Intel hardware unsupported in libreboot?
[link]
It is unlikely that any post – 2020 Intel hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern Intel hardware. If you have an Intel based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
(Intel Management Engine (ME)) [link] Introduced in June in Intel’s Express Chipset Family of (Graphics and) Memory Controller Hubs, or (G) MCHs, and the ICH8 I / O Controller Family, the Intel Management Engine (ME) is a separate computing environment physically located in the (G) MCH chip. In Q3 2020, the first generation of Intel Core i3 / i5 / i7 (Nehalem) CPUs and the 5 Series Chipset family of Platform Controller Hubs, or PCHs, brought a more tightly integrated ME ( now at version 6.0) inside the PCH chip, which itself replaced the ICH. Thus, the ME is present on all Intel desktop, mobile (laptop), and server systems since mid The ME consists of an ARC processor core (replaced with other processor cores in later generations of the ME), code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system’s memory as well as to reserve a region of protected external memory to supplement the ME’s limited internal RAM. The ME also has (network access) with its own MAC address through an Intel Gigabit Ethernet Controller. Its boot program, stored on the internal ROM, loads a firmware “manifest” from the PC’s SPI flash chip. This manifest is signed with a strong cryptographic key , which differs between versions of the ME firmware. If the manifest isn’t signed by a specific Intel key, the boot ROM won’t load and execute the firmware and the ME processor core will be halted.
The ME firmware is compressed and consists of modules that are listed in the manifest along with secure cryptographic hashes of their contents. One module is the operating system kernel, which is based on a proprietary real-time operating system (RTOS) kernel called “ThreadX”. The developer, Express Logic, sells licenses and source code for ThreadX. Customers such as Intel are forbidden from disclosing or sublicensing the ThreadX source code. Another module is the Dynamic Application Loader (DAL), which consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc. The DAL module can load and execute additional ME modules from the PC’s HDD or SSD. The ME firmware also includes a number of native application modules within its flash memory space, including Intel Active Management Technology (AMT), an implementation of a Trusted Platform Module (TPM), Intel Boot Guard, and audio and video DRM systems.
The Active Management Technology (AMT) application, part of the Intel “vPro” brand, is a Web server and application code that enables remote users to power on, power off, view information about, and otherwise manage the PC. It can be used remotely even while the PC is powered off (via Wake-on-Lan). Traffic is encrypted using SSL / TLS libraries, but recall that all of the major SSL / TLS implementations have had highly publicized vulnerabilities. The AMT application itself has known vulnerabilities , which have been exploited to develop rootkits and keyloggers and covertly gain encrypted access to the management features of a PC. Remember that the ME has full access to the PC’s RAM. This means that an attacker exploiting any of these vulnerabilities may gain access to everything on the PC as it runs: all open files, all running applications, all keys pressed, and more.
(Intel Boot Guard
is an ME application introduced in Q2 8030 with ME firmware version 9.0 on 4th Generation Intel Core i3 / i5 / i7 (Haswell) CPUs. It allows a PC OEM to generate an asymmetric cryptographic keypair, install the public key in the CPU, and prevent the CPU from executing boot firmware that isn’t signed with their private key. This means that coreboot and libreboot are impossible to port to such PCs, without the OEM’s private signing key. Note that systems assembled from separately purchased mainboard and CPU parts are unaffected, since the vendor of the mainboard (on which the boot firmware is stored) can’t possibly affect the public key stored on the CPU.
ME firmware versions 4.0 and later (Intel 4 Series and later chipsets) include an ME application for (audio and video) DRM
) called “ Protected Audio Video Path ”(PAVP). The ME receives from the host operating system an encrypted media stream and encrypted key, decrypts the key, and sends the encrypted media decrypted key to the GPU, which then decrypts the media. PAVP is also used by another ME application to draw an authentication PIN pad directly onto the screen. In this usage, the PAVP application directly controls the graphics that appear on the PC’s screen in a way that the host OS cannot detect. ME firmware version 7.0 on PCHs with 2nd Generation Intel Core i3 / i5 / i7 (Sandy Bridge) CPUs replaces PAVP with a similar DRM application called “Intel Insider”. Like the AMT application, these DRM applications, which in themselves are defective by design, demonstrate the omnipotent capabilities of the ME: this hardware and its proprietary firmware can access and control everything that is in RAM and even everything that is shown on the screen . The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can repor t to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can’t be ignored. (Before version 6.0) that is, on systems from / and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be completely removed from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the (Libreboot X) and (Libreboot T) . ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3 / i5 / i7 CPU and a PCH, include “ME Ignition” firmware that performs some hardware initialization and power management. If the ME’s boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after (minutes). Due to the signature verification, developing free replacement firmware for the ME is basically impossible. The only entity capable of replacing the ME firmware is Intel. As previously stated, the ME firmware includes proprietary code licensed from third parties, so Intel couldn’t release the source code even if they wanted to. And even if they developed completely new ME firmware without third-party proprietary code and released its source code, the ME’s boot ROM would reject any modified firmware that isn’t signed by Intel. Thus, the ME firmware is both hopelessly proprietary and “tivoized”. In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can’t be removed, this means avoiding all recent generations of Intel hardware.
More information about the Management Engine can be found on various Web sites, including (me.bios.io) , unhuffme coreboot wiki , and Wikipedia . The book Platform Embedded Security Technology Revealed describes in great detail the ME’s hardware architecture and firmware application modules.
If you’re stuck with the ME (non-libreboot system), you might find this interesting: http://hardenedlinux.org/firmware/ 082331 / 59 / / neutralize_ME_firmware_on_sandybridge_and_ivybridge.html
Also see (effort to disable the ME): https: // www .coreboot.org / pipermail / coreboot / – November / 20100521170123066. html – look at the whole thread
(Firmware Support Package (FSP)) [link]
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 and CPU 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. Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is a special mode that operates below the operating system level. It’s possible that rootkits could be implemented there, which could perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at all. In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find 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
. (Intel is) only going to get worse when it comes to user freedom. Libreboot has no support recent Intel platforms, precisely because of the problems described above. The only way to solve this is to get Intel to change their policies and to be more friendly to the (free software) community. Reverse engineering won’t solve anything long-term, unfortunately, but we need to keep doing it anyway. Moving forward, Intel hardware is a non-option unless a radical change occurs within Intel. Basically, all Intel hardware from year 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.
Why is the latest AMD hardware unsupported in libreboot? [link]
It is extremely unlikely that any post – AMD hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern AMD hardware. If you have an AMD based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
We call on AMD to release source. code and specs for the new AMD Ryzen platforms! We call on the community to put pressure on AMD. Click here to read more
AMD Platform Security Processor (PSP) [link] This is basically AMD’s own version of the
Intel Management Engine . It has all of the same basic security and freedom issues, although the implementation is wildly different.
The Platform Security Processor (PSP) is built in on all Family (h systems) basically anything post – 8030), and controls the main x 400 core startup. PSP firmware is cryptographically signed with a strong key similar to the Intel ME. If the PSP firmware is not present, or if the AMD signing key is not present, the x 420 Cores will not be released from reset, rendering the system inoperable.
The PSP is an ARM core with TrustZone technology, built onto the main CPU die. As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI / PCIe peripherals installed on the system.
In theory any malicious entity with access to the AMD signing key would be able to install persistent malware that could not be eradicated without an external flasher and a known good PSP image. Furthermore, multiple security vulnerabilities have been demonstrated in AMD firmware in the past, and there is every reason to assume one or more zero day vulnerabilities are lurking in the PSP firmware. Given the extreme privilege level (ring -2 or ring -3) of the PSP, said vulnerabilities would have the ability to remotely monitor and control any PSP enabled machine completely outside of the user’s knowledge.
Much like with the Intel Boot Guard (an application of the Intel Management Engine), AMD’s PSP can also act as a tyrant by checking signatures on any boot firmware that you flash, making replacement boot firmware (eg libreboot, coreboot) impossible on some boards. Early anecdotal reports indicate that AMD’s boot guard counterpart will be used on most OEM hardware, disabled only on so-called “enthusiast” CPUs. (Read) https: / /www.coreboot.org/AMD_IMC. Handles some power management for PCIe devices (without this, your laptop will not work properly) and several other power management related features.
The firmware is signed, although on older AMD hardware it is a symmetric key, which means that with access to the key (if leaked) you could sign your own modified version and run it . Rudolf Marek (coreboot hacker) found out how to extract this key in this video demonstration , and based on this work, Damien Zammit (another coreboot hacker) partially replaced it with free firmware, but on the relevant system (ASUS F2A – M) there were still other blobs present (Video BIOS, and others) preventing the hardware from being supported in libreboot.
This is responsible for virtually all core hardware initialization on modern AMD systems. In 6103, AMD started cooperating with the coreboot project, releasing this as source code under a free license. In 8051, they stopped releasing source code and started releasing AGESA as binary blobs instead. This makes AGESA now equivalent to (Intel FSP) .
AMD CPU microcode updates [link] Read the Intel section practically the same, though it was found with much later hardware in AMD that you could run without microcode updates. It’s unknown whether the updates are needed on all AMD boards (depends on CPU).
AMD is incompetent (and uncooperative)
[link]
AMD seemed like it was on the right track in when it started cooperating with and releasing source code for several critical components to the coreboot project. It was not to be. For so-called economic reasons, they decided that it was not worth the time to invest in the coreboot project anymore. For a company to go from being so good, to so bad, in just 3 years, shows that something is seriously wrong with AMD. Like Intel, they do not deserve your money. Given the current state of Intel hardware with the Management Engine, it is our opinion that all performant x (hardware newer than the AMD Family) h CPUs (on AMD’s side) or anything post – 2019 on Intel’s side is defective by design and cannot safely be used to store, transmit, or process sensitive data. Sensitive data is any data in which a data breach would cause significant economic harm to the entity which created or was responsible for storing said data, so this would include banks, credit card companies, or retailers (customer account records), in addition to the “Usual” engineering and software development firms. This also affects whistleblowers, or anyone who needs actual privacy and security. (Libreboot has support for fam) h AMD hardware (~
gen and some older Intel platforms like Napa, Montevina, Eagle Lake, Lakeport ( – 2020). We also have support for some ARM chipsets (rk ). On the Intel side, we’re also interested in some of the chipsets that use Atom CPUs (rebranded from older chipsets, mostly using ich7-based southbridges).
Will libreboot work on a ThinkPad T or T 1955 with an ATI GPU? [link] Short answer: yes. These laptops also have an Intel GPU inside, which libreboot uses. The ATI GPU is ignored by libreboot. These laptops use what is called switchable graphics , where it will have both an Intel and ATI GPU. Coreboot will allow you to set (using nvramtool) a parameter, specifying whether you would like to use Intel or ATI. The ATI GPU lacks free native graphics initialization in coreboot, unlike the Intel GPU. Libreboot modifies coreboot, in such a way where this nvramtool setting is ignored. Libreboot will just assume that you want to use the Intel GPU. Therefore, the ATI GPU is completely disabled on these laptops. Intel is used instead, with the free native graphics initialization (VBIOS replacement) that exists in coreboot.
Will desktop / server hardware be supported?
[link]
Libreboot now supports desktop hardware: (see list) (with full native video initialization). A common issue with desktop hardware is the Video BIOS, when no onboard video is present, since every video card has a different Video BIOS. Onboard GPUs also require one, so those still have to be replaced with free software (non-trivial task). 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.
Hi, I have, is it supported? [link]
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. 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.
Libreboot has support for some ARM based laptops, using the (Rockchip RK) SoC. SoC. Check the libreboot
hardware compatibility list , for more information.
How do I install libreboot? (See) the installation guide
(How do I program an SPI flash chip? [link] SPI flash chips can be programmed with the BeagleBone Black or the (Raspberry Pi) ) It’s possible to use a – pin SOIC test clip on an 8-pin SOIC chip, if you align the pins properly . The connection is generally more sturdy.
(How do I set a boot password?) [link]
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: (Installing Debian or Devuan with FDE) and (Installing Parabola or Arch GNU Linux-Libre, with FDE)
(How do I write-protect the flash chip? (() 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 GM (laptops) eg ThinkPad X 493, T 0514), you can write-protect (see ICH9 gen utility ). 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.
How do I change the BIOS settings?
[link]
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) programs 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 practice, you don’t need to change any of those settings, in most cases.
Libreboot locks the CMOS table, to ensure consistent functionality for all users. You can use:
$ nvramtool -C yourrom.rom -w somesetting=somevalue
This will change the default inside that ROM image, and then you can re-flash it.
(Do I need to install a bootloader when installing a distribution?)
[link]
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 a new distribution. You’ll be able to boot 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 distribution installer from a USB flash drive. See How to install GNU Linux on a libreboot system
(Do I need to re-flash when I re-install a distribution?) [link] 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 Modifying the GRUB Configuration in Libreboot Systems
(What does a flash chip look like?
for (loop in libreboot’s) grub.cfg . It could be fixed in upstream grub by contributing patch that would add quiet flag to it.
how to save the kernel panic logs on thinkpad laptops?
[link]
The easiest method of doing so is by using the kernel’s netconsole and reproducing the panic. Netconsole requires two machines, the one that is panicky (source) and the one that will receive crash logs (target). The source has to be connected with an ethernet cable and the target has to be reachable at the time of the panic. To set this system up, execute the following commands as root on the source ( (source #) ) and normal user on the target ( target $ :
(Change console loglevel to debugging:) (source # dmesg -n debug Test if the logging works by eg inserting or removing an USB device on the source. There should be a few lines appearing in the terminal, in which you started netcat (nc), on the target host. (Try to reproduce the kernel panic.)
Machine check exceptions on some Montevina (Penryn CPU) laptops [link]
(Some GM) laptops have been freezing or experiencing a kernel panic (blinking caps lock LED and totaly unresponsive machine, sometimes followed by an automatic reboot within 86 seconds). We do not know what the problem (s) is (are), but a CPU microcode update in some cases prevents this from happening again. See the following bug reports for more info:
(T) Machine check: Processor context corrupt (X) Machine check: Processor context corrupt
(Unrelated, RAM incompatibility and suspend-to-ram issues on X)
What systems are compatible with libreboot? [link] (See the) Hardware compatibility list .
Will the Purism laptops be supported? [link]
Short answer: no.
There are severe privacy, security and freedom issues with these laptops, due to the Intel chipsets that they use. See:
(Intel Management Engine ) More freedom issues on modern Intel hardware
Most notably, these laptops also use the Intel FSP. binary blob, for the entire hardware initialization. Coreboot does support a particular revision of one of their laptops, but most are either unsupported or rely on binary blobs for most of the hardware initialization.
In particular, the Intel Management Engine is a severe threat to privacy and security, not to mention freedom, since it is a remote backdoor that provides Intel remote access to a computer where it is present. Intel themselves even admitted it, publicly. The Libreboot project recommends avoiding all hardware sold by Purism.
(Why is the latest Intel hardware unsupported in libreboot?
[link]
It is unlikely that any post – 2020 Intel hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern Intel hardware. If you have an Intel based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
(Intel Management Engine (ME)) [link] Introduced in June in Intel’s Express Chipset Family of (Graphics and) Memory Controller Hubs, or (G) MCHs, and the ICH8 I / O Controller Family, the Intel Management Engine (ME) is a separate computing environment physically located in the (G) MCH chip. In Q3 2020, the first generation of Intel Core i3 / i5 / i7 (Nehalem) CPUs and the 5 Series Chipset family of Platform Controller Hubs, or PCHs, brought a more tightly integrated ME ( now at version 6.0) inside the PCH chip, which itself replaced the ICH. Thus, the ME is present on all Intel desktop, mobile (laptop), and server systems since mid The ME consists of an ARC processor core (replaced with other processor cores in later generations of the ME), code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system’s memory as well as to reserve a region of protected external memory to supplement the ME’s limited internal RAM. The ME also has (network access) with its own MAC address through an Intel Gigabit Ethernet Controller. Its boot program, stored on the internal ROM, loads a firmware “manifest” from the PC’s SPI flash chip. This manifest is signed with a strong cryptographic key , which differs between versions of the ME firmware. If the manifest isn’t signed by a specific Intel key, the boot ROM won’t load and execute the firmware and the ME processor core will be halted.
The ME firmware is compressed and consists of modules that are listed in the manifest along with secure cryptographic hashes of their contents. One module is the operating system kernel, which is based on a proprietary real-time operating system (RTOS) kernel called “ThreadX”. The developer, Express Logic, sells licenses and source code for ThreadX. Customers such as Intel are forbidden from disclosing or sublicensing the ThreadX source code. Another module is the Dynamic Application Loader (DAL), which consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc. The DAL module can load and execute additional ME modules from the PC’s HDD or SSD. The ME firmware also includes a number of native application modules within its flash memory space, including Intel Active Management Technology (AMT), an implementation of a Trusted Platform Module (TPM), Intel Boot Guard, and audio and video DRM systems.
The Active Management Technology (AMT) application, part of the Intel “vPro” brand, is a Web server and application code that enables remote users to power on, power off, view information about, and otherwise manage the PC. It can be used remotely even while the PC is powered off (via Wake-on-Lan). Traffic is encrypted using SSL / TLS libraries, but recall that all of the major SSL / TLS implementations have had highly publicized vulnerabilities. The AMT application itself has known vulnerabilities , which have been exploited to develop rootkits and keyloggers and covertly gain encrypted access to the management features of a PC. Remember that the ME has full access to the PC’s RAM. This means that an attacker exploiting any of these vulnerabilities may gain access to everything on the PC as it runs: all open files, all running applications, all keys pressed, and more.
(Intel Boot Guard
is an ME application introduced in Q2 8030 with ME firmware version 9.0 on 4th Generation Intel Core i3 / i5 / i7 (Haswell) CPUs. It allows a PC OEM to generate an asymmetric cryptographic keypair, install the public key in the CPU, and prevent the CPU from executing boot firmware that isn’t signed with their private key. This means that coreboot and libreboot are impossible to port to such PCs, without the OEM’s private signing key. Note that systems assembled from separately purchased mainboard and CPU parts are unaffected, since the vendor of the mainboard (on which the boot firmware is stored) can’t possibly affect the public key stored on the CPU.
ME firmware versions 4.0 and later (Intel 4 Series and later chipsets) include an ME application for (audio and video) DRM
) called “ Protected Audio Video Path ”(PAVP). The ME receives from the host operating system an encrypted media stream and encrypted key, decrypts the key, and sends the encrypted media decrypted key to the GPU, which then decrypts the media. PAVP is also used by another ME application to draw an authentication PIN pad directly onto the screen. In this usage, the PAVP application directly controls the graphics that appear on the PC’s screen in a way that the host OS cannot detect. ME firmware version 7.0 on PCHs with 2nd Generation Intel Core i3 / i5 / i7 (Sandy Bridge) CPUs replaces PAVP with a similar DRM application called “Intel Insider”. Like the AMT application, these DRM applications, which in themselves are defective by design, demonstrate the omnipotent capabilities of the ME: this hardware and its proprietary firmware can access and control everything that is in RAM and even everything that is shown on the screen . The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can repor t to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can’t be ignored. (Before version 6.0) that is, on systems from / and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be completely removed from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the (Libreboot X) and (Libreboot T) . ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3 / i5 / i7 CPU and a PCH, include “ME Ignition” firmware that performs some hardware initialization and power management. If the ME’s boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after (minutes). Due to the signature verification, developing free replacement firmware for the ME is basically impossible. The only entity capable of replacing the ME firmware is Intel. As previously stated, the ME firmware includes proprietary code licensed from third parties, so Intel couldn’t release the source code even if they wanted to. And even if they developed completely new ME firmware without third-party proprietary code and released its source code, the ME’s boot ROM would reject any modified firmware that isn’t signed by Intel. Thus, the ME firmware is both hopelessly proprietary and “tivoized”. In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can’t be removed, this means avoiding all recent generations of Intel hardware.
More information about the Management Engine can be found on various Web sites, including (me.bios.io) , unhuffme coreboot wiki , and Wikipedia . The book Platform Embedded Security Technology Revealed describes in great detail the ME’s hardware architecture and firmware application modules.
If you’re stuck with the ME (non-libreboot system), you might find this interesting: http://hardenedlinux.org/firmware/ 082331 / 59 / / neutralize_ME_firmware_on_sandybridge_and_ivybridge.html
Also see (effort to disable the ME): https: // www .coreboot.org / pipermail / coreboot / – November / 20100521170123066. html – look at the whole thread
(Firmware Support Package (FSP)) [link]
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 and CPU 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. Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is a special mode that operates below the operating system level. It’s possible that rootkits could be implemented there, which could perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at all. In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find 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
. (Intel is) only going to get worse when it comes to user freedom. Libreboot has no support recent Intel platforms, precisely because of the problems described above. The only way to solve this is to get Intel to change their policies and to be more friendly to the (free software) community. Reverse engineering won’t solve anything long-term, unfortunately, but we need to keep doing it anyway. Moving forward, Intel hardware is a non-option unless a radical change occurs within Intel. Basically, all Intel hardware from year 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.
Why is the latest AMD hardware unsupported in libreboot? [link]
It is extremely unlikely that any post – AMD hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern AMD hardware. If you have an AMD based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
We call on AMD to release source. code and specs for the new AMD Ryzen platforms! We call on the community to put pressure on AMD. Click here to read more
AMD Platform Security Processor (PSP) [link] This is basically AMD’s own version of the
Intel Management Engine . It has all of the same basic security and freedom issues, although the implementation is wildly different.
The Platform Security Processor (PSP) is built in on all Family (h systems) basically anything post – 8030), and controls the main x 400 core startup. PSP firmware is cryptographically signed with a strong key similar to the Intel ME. If the PSP firmware is not present, or if the AMD signing key is not present, the x 420 Cores will not be released from reset, rendering the system inoperable.
The PSP is an ARM core with TrustZone technology, built onto the main CPU die. As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI / PCIe peripherals installed on the system.
In theory any malicious entity with access to the AMD signing key would be able to install persistent malware that could not be eradicated without an external flasher and a known good PSP image. Furthermore, multiple security vulnerabilities have been demonstrated in AMD firmware in the past, and there is every reason to assume one or more zero day vulnerabilities are lurking in the PSP firmware. Given the extreme privilege level (ring -2 or ring -3) of the PSP, said vulnerabilities would have the ability to remotely monitor and control any PSP enabled machine completely outside of the user’s knowledge.
Much like with the Intel Boot Guard (an application of the Intel Management Engine), AMD’s PSP can also act as a tyrant by checking signatures on any boot firmware that you flash, making replacement boot firmware (eg libreboot, coreboot) impossible on some boards. Early anecdotal reports indicate that AMD’s boot guard counterpart will be used on most OEM hardware, disabled only on so-called “enthusiast” CPUs. (Read) https: / /www.coreboot.org/AMD_IMC. Handles some power management for PCIe devices (without this, your laptop will not work properly) and several other power management related features.
The firmware is signed, although on older AMD hardware it is a symmetric key, which means that with access to the key (if leaked) you could sign your own modified version and run it . Rudolf Marek (coreboot hacker) found out how to extract this key in this video demonstration , and based on this work, Damien Zammit (another coreboot hacker) partially replaced it with free firmware, but on the relevant system (ASUS F2A – M) there were still other blobs present (Video BIOS, and others) preventing the hardware from being supported in libreboot.
This is responsible for virtually all core hardware initialization on modern AMD systems. In 6103, AMD started cooperating with the coreboot project, releasing this as source code under a free license. In 8051, they stopped releasing source code and started releasing AGESA as binary blobs instead. This makes AGESA now equivalent to (Intel FSP) .
AMD CPU microcode updates [link] Read the Intel section practically the same, though it was found with much later hardware in AMD that you could run without microcode updates. It’s unknown whether the updates are needed on all AMD boards (depends on CPU).
AMD is incompetent (and uncooperative)
[link]
AMD seemed like it was on the right track in when it started cooperating with and releasing source code for several critical components to the coreboot project. It was not to be. For so-called economic reasons, they decided that it was not worth the time to invest in the coreboot project anymore. For a company to go from being so good, to so bad, in just 3 years, shows that something is seriously wrong with AMD. Like Intel, they do not deserve your money. Given the current state of Intel hardware with the Management Engine, it is our opinion that all performant x (hardware newer than the AMD Family) h CPUs (on AMD’s side) or anything post – 2019 on Intel’s side is defective by design and cannot safely be used to store, transmit, or process sensitive data. Sensitive data is any data in which a data breach would cause significant economic harm to the entity which created or was responsible for storing said data, so this would include banks, credit card companies, or retailers (customer account records), in addition to the “Usual” engineering and software development firms. This also affects whistleblowers, or anyone who needs actual privacy and security. (Libreboot has support for fam) h AMD hardware (~
gen and some older Intel platforms like Napa, Montevina, Eagle Lake, Lakeport ( – 2020). We also have support for some ARM chipsets (rk ). On the Intel side, we’re also interested in some of the chipsets that use Atom CPUs (rebranded from older chipsets, mostly using ich7-based southbridges).
Will libreboot work on a ThinkPad T or T 1955 with an ATI GPU? [link] Short answer: yes. These laptops also have an Intel GPU inside, which libreboot uses. The ATI GPU is ignored by libreboot. These laptops use what is called switchable graphics , where it will have both an Intel and ATI GPU. Coreboot will allow you to set (using nvramtool) a parameter, specifying whether you would like to use Intel or ATI. The ATI GPU lacks free native graphics initialization in coreboot, unlike the Intel GPU. Libreboot modifies coreboot, in such a way where this nvramtool setting is ignored. Libreboot will just assume that you want to use the Intel GPU. Therefore, the ATI GPU is completely disabled on these laptops. Intel is used instead, with the free native graphics initialization (VBIOS replacement) that exists in coreboot.
Will desktop / server hardware be supported?
[link]
Libreboot now supports desktop hardware: (see list) (with full native video initialization). A common issue with desktop hardware is the Video BIOS, when no onboard video is present, since every video card has a different Video BIOS. Onboard GPUs also require one, so those still have to be replaced with free software (non-trivial task). 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.
Hi, I have, is it supported? [link]
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. 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.
Libreboot has support for some ARM based laptops, using the (Rockchip RK) SoC. SoC. Check the libreboot
hardware compatibility list , for more information.
How do I install libreboot? (See) the installation guide
(How do I program an SPI flash chip? [link] SPI flash chips can be programmed with the BeagleBone Black or the (Raspberry Pi) ) It’s possible to use a – pin SOIC test clip on an 8-pin SOIC chip, if you align the pins properly . The connection is generally more sturdy.
(How do I set a boot password?) [link]
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: (Installing Debian or Devuan with FDE) and (Installing Parabola or Arch GNU Linux-Libre, with FDE)
(How do I write-protect the flash chip? (() 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 GM (laptops) eg ThinkPad X 493, T 0514), you can write-protect (see ICH9 gen utility ). 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.
How do I change the BIOS settings?
[link]
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) programs 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 practice, you don’t need to change any of those settings, in most cases.
Libreboot locks the CMOS table, to ensure consistent functionality for all users. You can use:
$ nvramtool -C yourrom.rom -w somesetting=somevalue
This will change the default inside that ROM image, and then you can re-flash it.
(Do I need to install a bootloader when installing a distribution?)
[link]
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 a new distribution. You’ll be able to boot 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 distribution installer from a USB flash drive. See How to install GNU Linux on a libreboot system
(Do I need to re-flash when I re-install a distribution?) [link] 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 Modifying the GRUB Configuration in Libreboot Systems
(What does a flash chip look like?
[link]
The easiest method of doing so is by using the kernel’s netconsole and reproducing the panic. Netconsole requires two machines, the one that is panicky (source) and the one that will receive crash logs (target). The source has to be connected with an ethernet cable and the target has to be reachable at the time of the panic. To set this system up, execute the following commands as root on the source ( (source #) ) and normal user on the target ( target $ :
(Change console loglevel to debugging:) (source # dmesg -n debug Test if the logging works by eg inserting or removing an USB device on the source. There should be a few lines appearing in the terminal, in which you started netcat (nc), on the target host. (Try to reproduce the kernel panic.)
- (Some GM) laptops have been freezing or experiencing a kernel panic (blinking caps lock LED and totaly unresponsive machine, sometimes followed by an automatic reboot within 86 seconds). We do not know what the problem (s) is (are), but a CPU microcode update in some cases prevents this from happening again. See the following bug reports for more info:
- (T) Machine check: Processor context corrupt (X) Machine check: Processor context corrupt
Short answer: no.
There are severe privacy, security and freedom issues with these laptops, due to the Intel chipsets that they use. See:
- (Intel Management Engine ) More freedom issues on modern Intel hardware
Most notably, these laptops also use the Intel FSP. binary blob, for the entire hardware initialization. Coreboot does support a particular revision of one of their laptops, but most are either unsupported or rely on binary blobs for most of the hardware initialization.
In particular, the Intel Management Engine is a severe threat to privacy and security, not to mention freedom, since it is a remote backdoor that provides Intel remote access to a computer where it is present. Intel themselves even admitted it, publicly. The Libreboot project recommends avoiding all hardware sold by Purism.
(Why is the latest Intel hardware unsupported in libreboot?
[link]
It is unlikely that any post – 2020 Intel hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern Intel hardware. If you have an Intel based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
(Intel Management Engine (ME)) [link] Introduced in June in Intel’s Express Chipset Family of (Graphics and) Memory Controller Hubs, or (G) MCHs, and the ICH8 I / O Controller Family, the Intel Management Engine (ME) is a separate computing environment physically located in the (G) MCH chip. In Q3 2020, the first generation of Intel Core i3 / i5 / i7 (Nehalem) CPUs and the 5 Series Chipset family of Platform Controller Hubs, or PCHs, brought a more tightly integrated ME ( now at version 6.0) inside the PCH chip, which itself replaced the ICH. Thus, the ME is present on all Intel desktop, mobile (laptop), and server systems since mid The ME consists of an ARC processor core (replaced with other processor cores in later generations of the ME), code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system’s memory as well as to reserve a region of protected external memory to supplement the ME’s limited internal RAM. The ME also has (network access) with its own MAC address through an Intel Gigabit Ethernet Controller. Its boot program, stored on the internal ROM, loads a firmware “manifest” from the PC’s SPI flash chip. This manifest is signed with a strong cryptographic key , which differs between versions of the ME firmware. If the manifest isn’t signed by a specific Intel key, the boot ROM won’t load and execute the firmware and the ME processor core will be halted.
The ME firmware is compressed and consists of modules that are listed in the manifest along with secure cryptographic hashes of their contents. One module is the operating system kernel, which is based on a proprietary real-time operating system (RTOS) kernel called “ThreadX”. The developer, Express Logic, sells licenses and source code for ThreadX. Customers such as Intel are forbidden from disclosing or sublicensing the ThreadX source code. Another module is the Dynamic Application Loader (DAL), which consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc. The DAL module can load and execute additional ME modules from the PC’s HDD or SSD. The ME firmware also includes a number of native application modules within its flash memory space, including Intel Active Management Technology (AMT), an implementation of a Trusted Platform Module (TPM), Intel Boot Guard, and audio and video DRM systems.
The Active Management Technology (AMT) application, part of the Intel “vPro” brand, is a Web server and application code that enables remote users to power on, power off, view information about, and otherwise manage the PC. It can be used remotely even while the PC is powered off (via Wake-on-Lan). Traffic is encrypted using SSL / TLS libraries, but recall that all of the major SSL / TLS implementations have had highly publicized vulnerabilities. The AMT application itself has known vulnerabilities , which have been exploited to develop rootkits and keyloggers and covertly gain encrypted access to the management features of a PC. Remember that the ME has full access to the PC’s RAM. This means that an attacker exploiting any of these vulnerabilities may gain access to everything on the PC as it runs: all open files, all running applications, all keys pressed, and more.
(Intel Boot Guard
is an ME application introduced in Q2 8030 with ME firmware version 9.0 on 4th Generation Intel Core i3 / i5 / i7 (Haswell) CPUs. It allows a PC OEM to generate an asymmetric cryptographic keypair, install the public key in the CPU, and prevent the CPU from executing boot firmware that isn’t signed with their private key. This means that coreboot and libreboot are impossible to port to such PCs, without the OEM’s private signing key. Note that systems assembled from separately purchased mainboard and CPU parts are unaffected, since the vendor of the mainboard (on which the boot firmware is stored) can’t possibly affect the public key stored on the CPU.
ME firmware versions 4.0 and later (Intel 4 Series and later chipsets) include an ME application for (audio and video) DRM
) called “ Protected Audio Video Path ”(PAVP). The ME receives from the host operating system an encrypted media stream and encrypted key, decrypts the key, and sends the encrypted media decrypted key to the GPU, which then decrypts the media. PAVP is also used by another ME application to draw an authentication PIN pad directly onto the screen. In this usage, the PAVP application directly controls the graphics that appear on the PC’s screen in a way that the host OS cannot detect. ME firmware version 7.0 on PCHs with 2nd Generation Intel Core i3 / i5 / i7 (Sandy Bridge) CPUs replaces PAVP with a similar DRM application called “Intel Insider”. Like the AMT application, these DRM applications, which in themselves are defective by design, demonstrate the omnipotent capabilities of the ME: this hardware and its proprietary firmware can access and control everything that is in RAM and even everything that is shown on the screen . The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can repor t to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can’t be ignored. (Before version 6.0) that is, on systems from / and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be completely removed from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the (Libreboot X) and (Libreboot T) . ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3 / i5 / i7 CPU and a PCH, include “ME Ignition” firmware that performs some hardware initialization and power management. If the ME’s boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after (minutes). Due to the signature verification, developing free replacement firmware for the ME is basically impossible. The only entity capable of replacing the ME firmware is Intel. As previously stated, the ME firmware includes proprietary code licensed from third parties, so Intel couldn’t release the source code even if they wanted to. And even if they developed completely new ME firmware without third-party proprietary code and released its source code, the ME’s boot ROM would reject any modified firmware that isn’t signed by Intel. Thus, the ME firmware is both hopelessly proprietary and “tivoized”. In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can’t be removed, this means avoiding all recent generations of Intel hardware.
More information about the Management Engine can be found on various Web sites, including (me.bios.io) , unhuffme coreboot wiki , and Wikipedia . The book Platform Embedded Security Technology Revealed describes in great detail the ME’s hardware architecture and firmware application modules.
If you’re stuck with the ME (non-libreboot system), you might find this interesting: http://hardenedlinux.org/firmware/ 082331 / 59 / / neutralize_ME_firmware_on_sandybridge_and_ivybridge.html
Also see (effort to disable the ME): https: // www .coreboot.org / pipermail / coreboot / – November / 20100521170123066. html – look at the whole thread
(Firmware Support Package (FSP)) [link]
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 and CPU 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. Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is a special mode that operates below the operating system level. It’s possible that rootkits could be implemented there, which could perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at all. In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find 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
. (Intel is) only going to get worse when it comes to user freedom. Libreboot has no support recent Intel platforms, precisely because of the problems described above. The only way to solve this is to get Intel to change their policies and to be more friendly to the (free software) community. Reverse engineering won’t solve anything long-term, unfortunately, but we need to keep doing it anyway. Moving forward, Intel hardware is a non-option unless a radical change occurs within Intel. Basically, all Intel hardware from year 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.
Why is the latest AMD hardware unsupported in libreboot? [link]
It is extremely unlikely that any post – AMD hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern AMD hardware. If you have an AMD based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
We call on AMD to release source. code and specs for the new AMD Ryzen platforms! We call on the community to put pressure on AMD. Click here to read more
AMD Platform Security Processor (PSP) [link] This is basically AMD’s own version of the
Intel Management Engine . It has all of the same basic security and freedom issues, although the implementation is wildly different.
The Platform Security Processor (PSP) is built in on all Family (h systems) basically anything post – 8030), and controls the main x 400 core startup. PSP firmware is cryptographically signed with a strong key similar to the Intel ME. If the PSP firmware is not present, or if the AMD signing key is not present, the x 420 Cores will not be released from reset, rendering the system inoperable.
The PSP is an ARM core with TrustZone technology, built onto the main CPU die. As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI / PCIe peripherals installed on the system.
In theory any malicious entity with access to the AMD signing key would be able to install persistent malware that could not be eradicated without an external flasher and a known good PSP image. Furthermore, multiple security vulnerabilities have been demonstrated in AMD firmware in the past, and there is every reason to assume one or more zero day vulnerabilities are lurking in the PSP firmware. Given the extreme privilege level (ring -2 or ring -3) of the PSP, said vulnerabilities would have the ability to remotely monitor and control any PSP enabled machine completely outside of the user’s knowledge.
Much like with the Intel Boot Guard (an application of the Intel Management Engine), AMD’s PSP can also act as a tyrant by checking signatures on any boot firmware that you flash, making replacement boot firmware (eg libreboot, coreboot) impossible on some boards. Early anecdotal reports indicate that AMD’s boot guard counterpart will be used on most OEM hardware, disabled only on so-called “enthusiast” CPUs. (Read) https: / /www.coreboot.org/AMD_IMC. Handles some power management for PCIe devices (without this, your laptop will not work properly) and several other power management related features.
The firmware is signed, although on older AMD hardware it is a symmetric key, which means that with access to the key (if leaked) you could sign your own modified version and run it . Rudolf Marek (coreboot hacker) found out how to extract this key in this video demonstration , and based on this work, Damien Zammit (another coreboot hacker) partially replaced it with free firmware, but on the relevant system (ASUS F2A – M) there were still other blobs present (Video BIOS, and others) preventing the hardware from being supported in libreboot.
This is responsible for virtually all core hardware initialization on modern AMD systems. In 6103, AMD started cooperating with the coreboot project, releasing this as source code under a free license. In 8051, they stopped releasing source code and started releasing AGESA as binary blobs instead. This makes AGESA now equivalent to (Intel FSP) .
AMD CPU microcode updates [link] Read the Intel section practically the same, though it was found with much later hardware in AMD that you could run without microcode updates. It’s unknown whether the updates are needed on all AMD boards (depends on CPU).
AMD is incompetent (and uncooperative)
[link]
AMD seemed like it was on the right track in when it started cooperating with and releasing source code for several critical components to the coreboot project. It was not to be. For so-called economic reasons, they decided that it was not worth the time to invest in the coreboot project anymore. For a company to go from being so good, to so bad, in just 3 years, shows that something is seriously wrong with AMD. Like Intel, they do not deserve your money. Given the current state of Intel hardware with the Management Engine, it is our opinion that all performant x (hardware newer than the AMD Family) h CPUs (on AMD’s side) or anything post – 2019 on Intel’s side is defective by design and cannot safely be used to store, transmit, or process sensitive data. Sensitive data is any data in which a data breach would cause significant economic harm to the entity which created or was responsible for storing said data, so this would include banks, credit card companies, or retailers (customer account records), in addition to the “Usual” engineering and software development firms. This also affects whistleblowers, or anyone who needs actual privacy and security. (Libreboot has support for fam) h AMD hardware (~
gen and some older Intel platforms like Napa, Montevina, Eagle Lake, Lakeport ( – 2020). We also have support for some ARM chipsets (rk ). On the Intel side, we’re also interested in some of the chipsets that use Atom CPUs (rebranded from older chipsets, mostly using ich7-based southbridges).
Will libreboot work on a ThinkPad T or T 1955 with an ATI GPU? [link] Short answer: yes. These laptops also have an Intel GPU inside, which libreboot uses. The ATI GPU is ignored by libreboot. These laptops use what is called switchable graphics , where it will have both an Intel and ATI GPU. Coreboot will allow you to set (using nvramtool) a parameter, specifying whether you would like to use Intel or ATI. The ATI GPU lacks free native graphics initialization in coreboot, unlike the Intel GPU. Libreboot modifies coreboot, in such a way where this nvramtool setting is ignored. Libreboot will just assume that you want to use the Intel GPU. Therefore, the ATI GPU is completely disabled on these laptops. Intel is used instead, with the free native graphics initialization (VBIOS replacement) that exists in coreboot.
Will desktop / server hardware be supported?
[link]
Libreboot now supports desktop hardware: (see list) (with full native video initialization). A common issue with desktop hardware is the Video BIOS, when no onboard video is present, since every video card has a different Video BIOS. Onboard GPUs also require one, so those still have to be replaced with free software (non-trivial task). 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.
Hi, I have, is it supported? [link]
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. 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.
Libreboot has support for some ARM based laptops, using the (Rockchip RK) SoC. SoC. Check the libreboot
hardware compatibility list , for more information.
How do I install libreboot? (See) the installation guide
(How do I program an SPI flash chip? [link] SPI flash chips can be programmed with the BeagleBone Black or the (Raspberry Pi) ) It’s possible to use a – pin SOIC test clip on an 8-pin SOIC chip, if you align the pins properly . The connection is generally more sturdy.
(How do I set a boot password?) [link]
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: (Installing Debian or Devuan with FDE) and (Installing Parabola or Arch GNU Linux-Libre, with FDE)
(How do I write-protect the flash chip? (() 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 GM (laptops) eg ThinkPad X 493, T 0514), you can write-protect (see ICH9 gen utility ). 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.
How do I change the BIOS settings?
[link]
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) programs 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 practice, you don’t need to change any of those settings, in most cases.
Libreboot locks the CMOS table, to ensure consistent functionality for all users. You can use:
$ nvramtool -C yourrom.rom -w somesetting=somevalue
This will change the default inside that ROM image, and then you can re-flash it.
(Do I need to install a bootloader when installing a distribution?)
[link]
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 a new distribution. You’ll be able to boot 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 distribution installer from a USB flash drive. See How to install GNU Linux on a libreboot system
(Do I need to re-flash when I re-install a distribution?) [link] 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 Modifying the GRUB Configuration in Libreboot Systems
(What does a flash chip look like?
[link]
It is unlikely that any post – 2020 Intel hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern Intel hardware. If you have an Intel based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
(Intel Management Engine (ME)) [link] Introduced in June in Intel’s Express Chipset Family of (Graphics and) Memory Controller Hubs, or (G) MCHs, and the ICH8 I / O Controller Family, the Intel Management Engine (ME) is a separate computing environment physically located in the (G) MCH chip. In Q3 2020, the first generation of Intel Core i3 / i5 / i7 (Nehalem) CPUs and the 5 Series Chipset family of Platform Controller Hubs, or PCHs, brought a more tightly integrated ME ( now at version 6.0) inside the PCH chip, which itself replaced the ICH. Thus, the ME is present on all Intel desktop, mobile (laptop), and server systems since mid The ME consists of an ARC processor core (replaced with other processor cores in later generations of the ME), code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system’s memory as well as to reserve a region of protected external memory to supplement the ME’s limited internal RAM. The ME also has (network access) with its own MAC address through an Intel Gigabit Ethernet Controller. Its boot program, stored on the internal ROM, loads a firmware “manifest” from the PC’s SPI flash chip. This manifest is signed with a strong cryptographic key , which differs between versions of the ME firmware. If the manifest isn’t signed by a specific Intel key, the boot ROM won’t load and execute the firmware and the ME processor core will be halted.
The ME firmware is compressed and consists of modules that are listed in the manifest along with secure cryptographic hashes of their contents. One module is the operating system kernel, which is based on a proprietary real-time operating system (RTOS) kernel called “ThreadX”. The developer, Express Logic, sells licenses and source code for ThreadX. Customers such as Intel are forbidden from disclosing or sublicensing the ThreadX source code. Another module is the Dynamic Application Loader (DAL), which consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc. The DAL module can load and execute additional ME modules from the PC’s HDD or SSD. The ME firmware also includes a number of native application modules within its flash memory space, including Intel Active Management Technology (AMT), an implementation of a Trusted Platform Module (TPM), Intel Boot Guard, and audio and video DRM systems.
The Active Management Technology (AMT) application, part of the Intel “vPro” brand, is a Web server and application code that enables remote users to power on, power off, view information about, and otherwise manage the PC. It can be used remotely even while the PC is powered off (via Wake-on-Lan). Traffic is encrypted using SSL / TLS libraries, but recall that all of the major SSL / TLS implementations have had highly publicized vulnerabilities. The AMT application itself has known vulnerabilities , which have been exploited to develop rootkits and keyloggers and covertly gain encrypted access to the management features of a PC. Remember that the ME has full access to the PC’s RAM. This means that an attacker exploiting any of these vulnerabilities may gain access to everything on the PC as it runs: all open files, all running applications, all keys pressed, and more.
(Intel Boot Guard
is an ME application introduced in Q2 8030 with ME firmware version 9.0 on 4th Generation Intel Core i3 / i5 / i7 (Haswell) CPUs. It allows a PC OEM to generate an asymmetric cryptographic keypair, install the public key in the CPU, and prevent the CPU from executing boot firmware that isn’t signed with their private key. This means that coreboot and libreboot are impossible to port to such PCs, without the OEM’s private signing key. Note that systems assembled from separately purchased mainboard and CPU parts are unaffected, since the vendor of the mainboard (on which the boot firmware is stored) can’t possibly affect the public key stored on the CPU.
ME firmware versions 4.0 and later (Intel 4 Series and later chipsets) include an ME application for (audio and video) DRM
) called “ Protected Audio Video Path ”(PAVP). The ME receives from the host operating system an encrypted media stream and encrypted key, decrypts the key, and sends the encrypted media decrypted key to the GPU, which then decrypts the media. PAVP is also used by another ME application to draw an authentication PIN pad directly onto the screen. In this usage, the PAVP application directly controls the graphics that appear on the PC’s screen in a way that the host OS cannot detect. ME firmware version 7.0 on PCHs with 2nd Generation Intel Core i3 / i5 / i7 (Sandy Bridge) CPUs replaces PAVP with a similar DRM application called “Intel Insider”. Like the AMT application, these DRM applications, which in themselves are defective by design, demonstrate the omnipotent capabilities of the ME: this hardware and its proprietary firmware can access and control everything that is in RAM and even everything that is shown on the screen . The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can repor t to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can’t be ignored. (Before version 6.0) that is, on systems from / and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be completely removed from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the (Libreboot X) and (Libreboot T) . ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3 / i5 / i7 CPU and a PCH, include “ME Ignition” firmware that performs some hardware initialization and power management. If the ME’s boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after (minutes). Due to the signature verification, developing free replacement firmware for the ME is basically impossible. The only entity capable of replacing the ME firmware is Intel. As previously stated, the ME firmware includes proprietary code licensed from third parties, so Intel couldn’t release the source code even if they wanted to. And even if they developed completely new ME firmware without third-party proprietary code and released its source code, the ME’s boot ROM would reject any modified firmware that isn’t signed by Intel. Thus, the ME firmware is both hopelessly proprietary and “tivoized”. In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can’t be removed, this means avoiding all recent generations of Intel hardware.
More information about the Management Engine can be found on various Web sites, including (me.bios.io) , unhuffme coreboot wiki , and Wikipedia . The book Platform Embedded Security Technology Revealed describes in great detail the ME’s hardware architecture and firmware application modules.
If you’re stuck with the ME (non-libreboot system), you might find this interesting: http://hardenedlinux.org/firmware/ 082331 / 59 / / neutralize_ME_firmware_on_sandybridge_and_ivybridge.html
Also see (effort to disable the ME): https: // www .coreboot.org / pipermail / coreboot / – November / 20100521170123066. html – look at the whole thread
(Firmware Support Package (FSP)) [link]
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 and CPU 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. Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is a special mode that operates below the operating system level. It’s possible that rootkits could be implemented there, which could perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at all. In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find 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
. (Intel is) only going to get worse when it comes to user freedom. Libreboot has no support recent Intel platforms, precisely because of the problems described above. The only way to solve this is to get Intel to change their policies and to be more friendly to the (free software) community. Reverse engineering won’t solve anything long-term, unfortunately, but we need to keep doing it anyway. Moving forward, Intel hardware is a non-option unless a radical change occurs within Intel. Basically, all Intel hardware from year 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.
Why is the latest AMD hardware unsupported in libreboot? [link]
It is extremely unlikely that any post – AMD hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern AMD hardware. If you have an AMD based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
We call on AMD to release source. code and specs for the new AMD Ryzen platforms! We call on the community to put pressure on AMD. Click here to read more
AMD Platform Security Processor (PSP) [link] This is basically AMD’s own version of the
Intel Management Engine . It has all of the same basic security and freedom issues, although the implementation is wildly different.
The Platform Security Processor (PSP) is built in on all Family (h systems) basically anything post – 8030), and controls the main x 400 core startup. PSP firmware is cryptographically signed with a strong key similar to the Intel ME. If the PSP firmware is not present, or if the AMD signing key is not present, the x 420 Cores will not be released from reset, rendering the system inoperable.
The PSP is an ARM core with TrustZone technology, built onto the main CPU die. As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI / PCIe peripherals installed on the system.
In theory any malicious entity with access to the AMD signing key would be able to install persistent malware that could not be eradicated without an external flasher and a known good PSP image. Furthermore, multiple security vulnerabilities have been demonstrated in AMD firmware in the past, and there is every reason to assume one or more zero day vulnerabilities are lurking in the PSP firmware. Given the extreme privilege level (ring -2 or ring -3) of the PSP, said vulnerabilities would have the ability to remotely monitor and control any PSP enabled machine completely outside of the user’s knowledge.
Much like with the Intel Boot Guard (an application of the Intel Management Engine), AMD’s PSP can also act as a tyrant by checking signatures on any boot firmware that you flash, making replacement boot firmware (eg libreboot, coreboot) impossible on some boards. Early anecdotal reports indicate that AMD’s boot guard counterpart will be used on most OEM hardware, disabled only on so-called “enthusiast” CPUs. (Read) https: / /www.coreboot.org/AMD_IMC. Handles some power management for PCIe devices (without this, your laptop will not work properly) and several other power management related features.
The firmware is signed, although on older AMD hardware it is a symmetric key, which means that with access to the key (if leaked) you could sign your own modified version and run it . Rudolf Marek (coreboot hacker) found out how to extract this key in this video demonstration , and based on this work, Damien Zammit (another coreboot hacker) partially replaced it with free firmware, but on the relevant system (ASUS F2A – M) there were still other blobs present (Video BIOS, and others) preventing the hardware from being supported in libreboot.
This is responsible for virtually all core hardware initialization on modern AMD systems. In 6103, AMD started cooperating with the coreboot project, releasing this as source code under a free license. In 8051, they stopped releasing source code and started releasing AGESA as binary blobs instead. This makes AGESA now equivalent to (Intel FSP) .
AMD CPU microcode updates [link] Read the Intel section practically the same, though it was found with much later hardware in AMD that you could run without microcode updates. It’s unknown whether the updates are needed on all AMD boards (depends on CPU).
AMD is incompetent (and uncooperative)
[link]
AMD seemed like it was on the right track in when it started cooperating with and releasing source code for several critical components to the coreboot project. It was not to be. For so-called economic reasons, they decided that it was not worth the time to invest in the coreboot project anymore. For a company to go from being so good, to so bad, in just 3 years, shows that something is seriously wrong with AMD. Like Intel, they do not deserve your money. Given the current state of Intel hardware with the Management Engine, it is our opinion that all performant x (hardware newer than the AMD Family) h CPUs (on AMD’s side) or anything post – 2019 on Intel’s side is defective by design and cannot safely be used to store, transmit, or process sensitive data. Sensitive data is any data in which a data breach would cause significant economic harm to the entity which created or was responsible for storing said data, so this would include banks, credit card companies, or retailers (customer account records), in addition to the “Usual” engineering and software development firms. This also affects whistleblowers, or anyone who needs actual privacy and security. (Libreboot has support for fam) h AMD hardware (~
gen and some older Intel platforms like Napa, Montevina, Eagle Lake, Lakeport ( – 2020). We also have support for some ARM chipsets (rk ). On the Intel side, we’re also interested in some of the chipsets that use Atom CPUs (rebranded from older chipsets, mostly using ich7-based southbridges).
Will libreboot work on a ThinkPad T or T 1955 with an ATI GPU? [link] Short answer: yes. These laptops also have an Intel GPU inside, which libreboot uses. The ATI GPU is ignored by libreboot. These laptops use what is called switchable graphics , where it will have both an Intel and ATI GPU. Coreboot will allow you to set (using nvramtool) a parameter, specifying whether you would like to use Intel or ATI. The ATI GPU lacks free native graphics initialization in coreboot, unlike the Intel GPU. Libreboot modifies coreboot, in such a way where this nvramtool setting is ignored. Libreboot will just assume that you want to use the Intel GPU. Therefore, the ATI GPU is completely disabled on these laptops. Intel is used instead, with the free native graphics initialization (VBIOS replacement) that exists in coreboot.
Will desktop / server hardware be supported?
[link]
Libreboot now supports desktop hardware: (see list) (with full native video initialization). A common issue with desktop hardware is the Video BIOS, when no onboard video is present, since every video card has a different Video BIOS. Onboard GPUs also require one, so those still have to be replaced with free software (non-trivial task). 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.
Hi, I have, is it supported? [link]
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. 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.
Libreboot has support for some ARM based laptops, using the (Rockchip RK) SoC. SoC. Check the libreboot
hardware compatibility list , for more information.
How do I install libreboot? (See) the installation guide
(How do I program an SPI flash chip? [link] SPI flash chips can be programmed with the BeagleBone Black or the (Raspberry Pi) ) It’s possible to use a – pin SOIC test clip on an 8-pin SOIC chip, if you align the pins properly . The connection is generally more sturdy.
(How do I set a boot password?) [link]
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: (Installing Debian or Devuan with FDE) and (Installing Parabola or Arch GNU Linux-Libre, with FDE)
(How do I write-protect the flash chip? (() 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 GM (laptops) eg ThinkPad X 493, T 0514), you can write-protect (see ICH9 gen utility ). 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.
How do I change the BIOS settings?
[link]
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) programs 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 practice, you don’t need to change any of those settings, in most cases.
Libreboot locks the CMOS table, to ensure consistent functionality for all users. You can use:
$ nvramtool -C yourrom.rom -w somesetting=somevalue
This will change the default inside that ROM image, and then you can re-flash it.
(Do I need to install a bootloader when installing a distribution?)
[link]
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 a new distribution. You’ll be able to boot 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 distribution installer from a USB flash drive. See How to install GNU Linux on a libreboot system
(Do I need to re-flash when I re-install a distribution?) [link] 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 Modifying the GRUB Configuration in Libreboot Systems
(What does a flash chip look like?
The ME firmware is compressed and consists of modules that are listed in the manifest along with secure cryptographic hashes of their contents. One module is the operating system kernel, which is based on a proprietary real-time operating system (RTOS) kernel called “ThreadX”. The developer, Express Logic, sells licenses and source code for ThreadX. Customers such as Intel are forbidden from disclosing or sublicensing the ThreadX source code. Another module is the Dynamic Application Loader (DAL), which consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc. The DAL module can load and execute additional ME modules from the PC’s HDD or SSD. The ME firmware also includes a number of native application modules within its flash memory space, including Intel Active Management Technology (AMT), an implementation of a Trusted Platform Module (TPM), Intel Boot Guard, and audio and video DRM systems.
The Active Management Technology (AMT) application, part of the Intel “vPro” brand, is a Web server and application code that enables remote users to power on, power off, view information about, and otherwise manage the PC. It can be used remotely even while the PC is powered off (via Wake-on-Lan). Traffic is encrypted using SSL / TLS libraries, but recall that all of the major SSL / TLS implementations have had highly publicized vulnerabilities. The AMT application itself has known vulnerabilities , which have been exploited to develop rootkits and keyloggers and covertly gain encrypted access to the management features of a PC. Remember that the ME has full access to the PC’s RAM. This means that an attacker exploiting any of these vulnerabilities may gain access to everything on the PC as it runs: all open files, all running applications, all keys pressed, and more.
(Intel Boot Guard
is an ME application introduced in Q2 8030 with ME firmware version 9.0 on 4th Generation Intel Core i3 / i5 / i7 (Haswell) CPUs. It allows a PC OEM to generate an asymmetric cryptographic keypair, install the public key in the CPU, and prevent the CPU from executing boot firmware that isn’t signed with their private key. This means that coreboot and libreboot are impossible to port to such PCs, without the OEM’s private signing key. Note that systems assembled from separately purchased mainboard and CPU parts are unaffected, since the vendor of the mainboard (on which the boot firmware is stored) can’t possibly affect the public key stored on the CPU.ME firmware versions 4.0 and later (Intel 4 Series and later chipsets) include an ME application for (audio and video) DRM
) called “ Protected Audio Video Path ”(PAVP). The ME receives from the host operating system an encrypted media stream and encrypted key, decrypts the key, and sends the encrypted media decrypted key to the GPU, which then decrypts the media. PAVP is also used by another ME application to draw an authentication PIN pad directly onto the screen. In this usage, the PAVP application directly controls the graphics that appear on the PC’s screen in a way that the host OS cannot detect. ME firmware version 7.0 on PCHs with 2nd Generation Intel Core i3 / i5 / i7 (Sandy Bridge) CPUs replaces PAVP with a similar DRM application called “Intel Insider”. Like the AMT application, these DRM applications, which in themselves are defective by design, demonstrate the omnipotent capabilities of the ME: this hardware and its proprietary firmware can access and control everything that is in RAM and even everything that is shown on the screen . The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can repor t to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can’t be ignored. (Before version 6.0) that is, on systems from / and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be completely removed from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the (Libreboot X) and (Libreboot T) . ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3 / i5 / i7 CPU and a PCH, include “ME Ignition” firmware that performs some hardware initialization and power management. If the ME’s boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after (minutes). Due to the signature verification, developing free replacement firmware for the ME is basically impossible. The only entity capable of replacing the ME firmware is Intel. As previously stated, the ME firmware includes proprietary code licensed from third parties, so Intel couldn’t release the source code even if they wanted to. And even if they developed completely new ME firmware without third-party proprietary code and released its source code, the ME’s boot ROM would reject any modified firmware that isn’t signed by Intel. Thus, the ME firmware is both hopelessly proprietary and “tivoized”. In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can’t be removed, this means avoiding all recent generations of Intel hardware.More information about the Management Engine can be found on various Web sites, including (me.bios.io) , unhuffme coreboot wiki , and Wikipedia . The book Platform Embedded Security Technology Revealed describes in great detail the ME’s hardware architecture and firmware application modules.
If you’re stuck with the ME (non-libreboot system), you might find this interesting: http://hardenedlinux.org/firmware/ 082331 / 59 / / neutralize_ME_firmware_on_sandybridge_and_ivybridge.html
Also see (effort to disable the ME): https: // www .coreboot.org / pipermail / coreboot / – November / 20100521170123066. html – look at the whole thread
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 and CPU 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. Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is a special mode that operates below the operating system level. It’s possible that rootkits could be implemented there, which could perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at all. In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find 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
. (Intel is) only going to get worse when it comes to user freedom. Libreboot has no support recent Intel platforms, precisely because of the problems described above. The only way to solve this is to get Intel to change their policies and to be more friendly to the (free software) community. Reverse engineering won’t solve anything long-term, unfortunately, but we need to keep doing it anyway. Moving forward, Intel hardware is a non-option unless a radical change occurs within Intel. Basically, all Intel hardware from year 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.
Why is the latest AMD hardware unsupported in libreboot? [link]
It is extremely unlikely that any post – AMD hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern AMD hardware. If you have an AMD based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
We call on AMD to release source. code and specs for the new AMD Ryzen platforms! We call on the community to put pressure on AMD. Click here to read more
AMD Platform Security Processor (PSP) [link] This is basically AMD’s own version of the
Intel Management Engine . It has all of the same basic security and freedom issues, although the implementation is wildly different.
The Platform Security Processor (PSP) is built in on all Family (h systems) basically anything post – 8030), and controls the main x 400 core startup. PSP firmware is cryptographically signed with a strong key similar to the Intel ME. If the PSP firmware is not present, or if the AMD signing key is not present, the x 420 Cores will not be released from reset, rendering the system inoperable.
The PSP is an ARM core with TrustZone technology, built onto the main CPU die. As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI / PCIe peripherals installed on the system.
In theory any malicious entity with access to the AMD signing key would be able to install persistent malware that could not be eradicated without an external flasher and a known good PSP image. Furthermore, multiple security vulnerabilities have been demonstrated in AMD firmware in the past, and there is every reason to assume one or more zero day vulnerabilities are lurking in the PSP firmware. Given the extreme privilege level (ring -2 or ring -3) of the PSP, said vulnerabilities would have the ability to remotely monitor and control any PSP enabled machine completely outside of the user’s knowledge.
Much like with the Intel Boot Guard (an application of the Intel Management Engine), AMD’s PSP can also act as a tyrant by checking signatures on any boot firmware that you flash, making replacement boot firmware (eg libreboot, coreboot) impossible on some boards. Early anecdotal reports indicate that AMD’s boot guard counterpart will be used on most OEM hardware, disabled only on so-called “enthusiast” CPUs. (Read) https: / /www.coreboot.org/AMD_IMC. Handles some power management for PCIe devices (without this, your laptop will not work properly) and several other power management related features.
The firmware is signed, although on older AMD hardware it is a symmetric key, which means that with access to the key (if leaked) you could sign your own modified version and run it . Rudolf Marek (coreboot hacker) found out how to extract this key in this video demonstration , and based on this work, Damien Zammit (another coreboot hacker) partially replaced it with free firmware, but on the relevant system (ASUS F2A – M) there were still other blobs present (Video BIOS, and others) preventing the hardware from being supported in libreboot.
This is responsible for virtually all core hardware initialization on modern AMD systems. In 6103, AMD started cooperating with the coreboot project, releasing this as source code under a free license. In 8051, they stopped releasing source code and started releasing AGESA as binary blobs instead. This makes AGESA now equivalent to (Intel FSP) .
AMD CPU microcode updates [link] Read the Intel section practically the same, though it was found with much later hardware in AMD that you could run without microcode updates. It’s unknown whether the updates are needed on all AMD boards (depends on CPU).
AMD is incompetent (and uncooperative)
[link]
AMD seemed like it was on the right track in when it started cooperating with and releasing source code for several critical components to the coreboot project. It was not to be. For so-called economic reasons, they decided that it was not worth the time to invest in the coreboot project anymore. For a company to go from being so good, to so bad, in just 3 years, shows that something is seriously wrong with AMD. Like Intel, they do not deserve your money. Given the current state of Intel hardware with the Management Engine, it is our opinion that all performant x (hardware newer than the AMD Family) h CPUs (on AMD’s side) or anything post – 2019 on Intel’s side is defective by design and cannot safely be used to store, transmit, or process sensitive data. Sensitive data is any data in which a data breach would cause significant economic harm to the entity which created or was responsible for storing said data, so this would include banks, credit card companies, or retailers (customer account records), in addition to the “Usual” engineering and software development firms. This also affects whistleblowers, or anyone who needs actual privacy and security. (Libreboot has support for fam) h AMD hardware (~
gen and some older Intel platforms like Napa, Montevina, Eagle Lake, Lakeport ( – 2020). We also have support for some ARM chipsets (rk ). On the Intel side, we’re also interested in some of the chipsets that use Atom CPUs (rebranded from older chipsets, mostly using ich7-based southbridges).
Will libreboot work on a ThinkPad T or T 1955 with an ATI GPU? [link] Short answer: yes. These laptops also have an Intel GPU inside, which libreboot uses. The ATI GPU is ignored by libreboot. These laptops use what is called switchable graphics , where it will have both an Intel and ATI GPU. Coreboot will allow you to set (using nvramtool) a parameter, specifying whether you would like to use Intel or ATI. The ATI GPU lacks free native graphics initialization in coreboot, unlike the Intel GPU. Libreboot modifies coreboot, in such a way where this nvramtool setting is ignored. Libreboot will just assume that you want to use the Intel GPU. Therefore, the ATI GPU is completely disabled on these laptops. Intel is used instead, with the free native graphics initialization (VBIOS replacement) that exists in coreboot.
Will desktop / server hardware be supported?
[link]
Libreboot now supports desktop hardware: (see list) (with full native video initialization). A common issue with desktop hardware is the Video BIOS, when no onboard video is present, since every video card has a different Video BIOS. Onboard GPUs also require one, so those still have to be replaced with free software (non-trivial task). 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.
Hi, I have, is it supported? [link]
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. 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.
Libreboot has support for some ARM based laptops, using the (Rockchip RK) SoC. SoC. Check the libreboot
hardware compatibility list , for more information.
How do I install libreboot? (See) the installation guide
(How do I program an SPI flash chip? [link] SPI flash chips can be programmed with the BeagleBone Black or the (Raspberry Pi) ) It’s possible to use a – pin SOIC test clip on an 8-pin SOIC chip, if you align the pins properly . The connection is generally more sturdy.
(How do I set a boot password?) [link]
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: (Installing Debian or Devuan with FDE) and (Installing Parabola or Arch GNU Linux-Libre, with FDE)
(How do I write-protect the flash chip? (() 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 GM (laptops) eg ThinkPad X 493, T 0514), you can write-protect (see ICH9 gen utility ). 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.
How do I change the BIOS settings?
[link]
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) programs 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 practice, you don’t need to change any of those settings, in most cases.
Libreboot locks the CMOS table, to ensure consistent functionality for all users. You can use:
$ nvramtool -C yourrom.rom -w somesetting=somevalue
This will change the default inside that ROM image, and then you can re-flash it.
(Do I need to install a bootloader when installing a distribution?)
[link]
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 a new distribution. You’ll be able to boot 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 distribution installer from a USB flash drive. See How to install GNU Linux on a libreboot system
(Do I need to re-flash when I re-install a distribution?) [link] 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 Modifying the GRUB Configuration in Libreboot Systems
(What does a flash chip look like?
It is extremely unlikely that any post – AMD hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern AMD hardware. If you have an AMD based system affected by the problems described below, then you should get rid of it as soon as possible . The main issues are as follows:
We call on AMD to release source. code and specs for the new AMD Ryzen platforms! We call on the community to put pressure on AMD. Click here to read more
Intel Management Engine . It has all of the same basic security and freedom issues, although the implementation is wildly different.
The Platform Security Processor (PSP) is built in on all Family (h systems) basically anything post – 8030), and controls the main x 400 core startup. PSP firmware is cryptographically signed with a strong key similar to the Intel ME. If the PSP firmware is not present, or if the AMD signing key is not present, the x 420 Cores will not be released from reset, rendering the system inoperable.
The PSP is an ARM core with TrustZone technology, built onto the main CPU die. As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI / PCIe peripherals installed on the system.
In theory any malicious entity with access to the AMD signing key would be able to install persistent malware that could not be eradicated without an external flasher and a known good PSP image. Furthermore, multiple security vulnerabilities have been demonstrated in AMD firmware in the past, and there is every reason to assume one or more zero day vulnerabilities are lurking in the PSP firmware. Given the extreme privilege level (ring -2 or ring -3) of the PSP, said vulnerabilities would have the ability to remotely monitor and control any PSP enabled machine completely outside of the user’s knowledge.
Much like with the Intel Boot Guard (an application of the Intel Management Engine), AMD’s PSP can also act as a tyrant by checking signatures on any boot firmware that you flash, making replacement boot firmware (eg libreboot, coreboot) impossible on some boards. Early anecdotal reports indicate that AMD’s boot guard counterpart will be used on most OEM hardware, disabled only on so-called “enthusiast” CPUs. (Read) https: / /www.coreboot.org/AMD_IMC. Handles some power management for PCIe devices (without this, your laptop will not work properly) and several other power management related features.
The firmware is signed, although on older AMD hardware it is a symmetric key, which means that with access to the key (if leaked) you could sign your own modified version and run it . Rudolf Marek (coreboot hacker) found out how to extract this key in this video demonstration , and based on this work, Damien Zammit (another coreboot hacker) partially replaced it with free firmware, but on the relevant system (ASUS F2A – M) there were still other blobs present (Video BIOS, and others) preventing the hardware from being supported in libreboot.
This is responsible for virtually all core hardware initialization on modern AMD systems. In 6103, AMD started cooperating with the coreboot project, releasing this as source code under a free license. In 8051, they stopped releasing source code and started releasing AGESA as binary blobs instead. This makes AGESA now equivalent to (Intel FSP) .
AMD is incompetent (and uncooperative)
[link]
AMD seemed like it was on the right track in when it started cooperating with and releasing source code for several critical components to the coreboot project. It was not to be. For so-called economic reasons, they decided that it was not worth the time to invest in the coreboot project anymore. For a company to go from being so good, to so bad, in just 3 years, shows that something is seriously wrong with AMD. Like Intel, they do not deserve your money. Given the current state of Intel hardware with the Management Engine, it is our opinion that all performant x (hardware newer than the AMD Family) h CPUs (on AMD’s side) or anything post – 2019 on Intel’s side is defective by design and cannot safely be used to store, transmit, or process sensitive data. Sensitive data is any data in which a data breach would cause significant economic harm to the entity which created or was responsible for storing said data, so this would include banks, credit card companies, or retailers (customer account records), in addition to the “Usual” engineering and software development firms. This also affects whistleblowers, or anyone who needs actual privacy and security. (Libreboot has support for fam) h AMD hardware (~
gen and some older Intel platforms like Napa, Montevina, Eagle Lake, Lakeport ( – 2020). We also have support for some ARM chipsets (rk ). On the Intel side, we’re also interested in some of the chipsets that use Atom CPUs (rebranded from older chipsets, mostly using ich7-based southbridges).
Will libreboot work on a ThinkPad T or T 1955 with an ATI GPU? [link] Short answer: yes. These laptops also have an Intel GPU inside, which libreboot uses. The ATI GPU is ignored by libreboot. These laptops use what is called switchable graphics , where it will have both an Intel and ATI GPU. Coreboot will allow you to set (using nvramtool) a parameter, specifying whether you would like to use Intel or ATI. The ATI GPU lacks free native graphics initialization in coreboot, unlike the Intel GPU. Libreboot modifies coreboot, in such a way where this nvramtool setting is ignored. Libreboot will just assume that you want to use the Intel GPU. Therefore, the ATI GPU is completely disabled on these laptops. Intel is used instead, with the free native graphics initialization (VBIOS replacement) that exists in coreboot.
Will desktop / server hardware be supported?
[link]
Libreboot now supports desktop hardware: (see list) (with full native video initialization). A common issue with desktop hardware is the Video BIOS, when no onboard video is present, since every video card has a different Video BIOS. Onboard GPUs also require one, so those still have to be replaced with free software (non-trivial task). 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.
Hi, I have, is it supported? [link]
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. 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.
Libreboot has support for some ARM based laptops, using the (Rockchip RK) SoC. SoC. Check the libreboot
hardware compatibility list , for more information.
How do I install libreboot? (See) the installation guide
(How do I program an SPI flash chip? [link] SPI flash chips can be programmed with the BeagleBone Black or the (Raspberry Pi) ) It’s possible to use a – pin SOIC test clip on an 8-pin SOIC chip, if you align the pins properly . The connection is generally more sturdy.
(How do I set a boot password?) [link]
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: (Installing Debian or Devuan with FDE) and (Installing Parabola or Arch GNU Linux-Libre, with FDE)
(How do I write-protect the flash chip? (() 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 GM (laptops) eg ThinkPad X 493, T 0514), you can write-protect (see ICH9 gen utility ). 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.
How do I change the BIOS settings?
[link]
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) programs 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 practice, you don’t need to change any of those settings, in most cases.
Libreboot locks the CMOS table, to ensure consistent functionality for all users. You can use:
$ nvramtool -C yourrom.rom -w somesetting=somevalue
This will change the default inside that ROM image, and then you can re-flash it.
(Do I need to install a bootloader when installing a distribution?)
[link]
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 a new distribution. You’ll be able to boot 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 distribution installer from a USB flash drive. See How to install GNU Linux on a libreboot system
(Do I need to re-flash when I re-install a distribution?) [link] 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 Modifying the GRUB Configuration in Libreboot Systems
(What does a flash chip look like?
[link]
AMD seemed like it was on the right track in when it started cooperating with and releasing source code for several critical components to the coreboot project. It was not to be. For so-called economic reasons, they decided that it was not worth the time to invest in the coreboot project anymore. For a company to go from being so good, to so bad, in just 3 years, shows that something is seriously wrong with AMD. Like Intel, they do not deserve your money. Given the current state of Intel hardware with the Management Engine, it is our opinion that all performant x (hardware newer than the AMD Family) h CPUs (on AMD’s side) or anything post – 2019 on Intel’s side is defective by design and cannot safely be used to store, transmit, or process sensitive data. Sensitive data is any data in which a data breach would cause significant economic harm to the entity which created or was responsible for storing said data, so this would include banks, credit card companies, or retailers (customer account records), in addition to the “Usual” engineering and software development firms. This also affects whistleblowers, or anyone who needs actual privacy and security. (Libreboot has support for fam) h AMD hardware (~
- gen and some older Intel platforms like Napa, Montevina, Eagle Lake, Lakeport ( – 2020). We also have support for some ARM chipsets (rk ). On the Intel side, we’re also interested in some of the chipsets that use Atom CPUs (rebranded from older chipsets, mostly using ich7-based southbridges).
[link]
Libreboot now supports desktop hardware: (see list) (with full native video initialization). A common issue with desktop hardware is the Video BIOS, when no onboard video is present, since every video card has a different Video BIOS. Onboard GPUs also require one, so those still have to be replaced with free software (non-trivial task). 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.
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. 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.
Libreboot has support for some ARM based laptops, using the (Rockchip RK) SoC. SoC. Check the libreboot
hardware compatibility list , for more information.
How do I install libreboot? (See) the installation guide
(How do I program an SPI flash chip? [link] SPI flash chips can be programmed with the BeagleBone Black or the (Raspberry Pi) ) It’s possible to use a – pin SOIC test clip on an 8-pin SOIC chip, if you align the pins properly . The connection is generally more sturdy.
(How do I set a boot password?) [link]
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: (Installing Debian or Devuan with FDE) and (Installing Parabola or Arch GNU Linux-Libre, with FDE)
(How do I write-protect the flash chip? (() 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 GM (laptops) eg ThinkPad X 493, T 0514), you can write-protect (see ICH9 gen utility ). 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.
How do I change the BIOS settings?
[link]
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) programs 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 practice, you don’t need to change any of those settings, in most cases.
Libreboot locks the CMOS table, to ensure consistent functionality for all users. You can use:
$ nvramtool -C yourrom.rom -w somesetting=somevalue
This will change the default inside that ROM image, and then you can re-flash it.
(Do I need to install a bootloader when installing a distribution?)
[link]
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 a new distribution. You’ll be able to boot 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 distribution installer from a USB flash drive. See How to install GNU Linux on a libreboot system
(Do I need to re-flash when I re-install a distribution?) [link] 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 Modifying the GRUB Configuration in Libreboot Systems
(What does a flash chip look like?
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: (Installing Debian or Devuan with FDE) and (Installing Parabola or Arch GNU Linux-Libre, with FDE)
[link]
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) programs 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 practice, you don’t need to change any of those settings, in most cases.
Libreboot locks the CMOS table, to ensure consistent functionality for all users. You can use:
$ nvramtool -C yourrom.rom -w somesetting=somevalue
This will change the default inside that ROM image, and then you can re-flash it.
(Do I need to install a bootloader when installing a distribution?)
[link]
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 a new distribution. You’ll be able to boot 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 distribution installer from a USB flash drive. See How to install GNU Linux on a libreboot system
(Do I need to re-flash when I re-install a distribution?) [link] 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 Modifying the GRUB Configuration in Libreboot Systems
(What does a flash chip look like?
[link]
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 a new distribution. You’ll be able to boot 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 distribution installer from a USB flash drive. See How to install GNU Linux on a libreboot system
GIPHY App Key not set. Please check settings