Hardware compatibility
What systems are compatible with libreboot? #compatibility
See ../docs/hcl/index.html.
Several supported systems are also available with libreboot preinstalled.
Check the suppliers page for more information.
Back to top of page
Will the Purism Librem laptops be supported? #librem
Probably not. There are several privacy, security and freedom issues with these laptops, due to the Intel chipsets
that they use. See #intel. There are signed proprietary blobs which cannot be replaced
(e.g. Intel Management Engine and CPU microcode updates).
It uses the proprietary Intel FSP blob for the entire hardware initialization, which
Intel won't provide the source code for. The Video BIOS (initialization firmware
for the graphics hardware) is also proprietary. The libreboot project recommends avoiding this hardware entirely.
It will likely take many years to replace even one of these blobs, let alone all of them. Some of them (ME firmware and microcode) can't even be replaced,
which immediately disqualifies these laptops from being added to libreboot. Google engineers have tried
for many years to get source code from Intel, and to reverse engineer the blobs that Intel provides. So far, they have
been unsuccessful. Google is also one of the companies that funds the coreboot project, and they hire a lot of the core
developers, so it's not like they don't have vast resources at their disposal. Smaller companies have no chance.
The librem does have coreboot support, but it's pretty meaningless (it's shimboot, which
means that coreboot is just incorporating blobs. It's not real coreboot support,
but rather, what is shamelessly passed off as coreboot support these days, where
binary blobs for the entire hardware initialization is considered acceptable in the coreboot project).
It should be noted, that the coreboot port for librem was done by a lone Google software
developer (Duncan Laurie), not Purism, working independently. Purism had nothing to do with the port.
Back to top of page
Why is the latest Intel hardware unsupported in libreboot? #intel
It is extremely unlikely that any post-2008 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) #intelme
Introduced in June 2006 in Intel's 965 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 2009, 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 2006.
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 2013 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 report
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 2008/2009 and earlier), the ME can
be disabled by setting a couple of values in the SPI flash memory. The ME
firmware can then be removed entirely from the flash memory space. libreboot does this on the Intel 4 Series
systems that it supports, such as the Libreboot X200 and Libreboot T400. 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 Ingition" 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 30 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, the smashthestack network, coreboot wiki, and
Wikipedia. The book
Platform Embedded Security Technology Revealed describes in great
detail the ME's hardware architecture and firmware application modules.
Firmware Support Package (FSP) #fsp
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).
CPU microcode updates #microcode
All modern x86 CPUs (from Intel and AMD) use what is called microcode. CPUs are extremely complex,
and difficult to get right, so the circuitry is designed in a very generic way, where only basic instructions
are handled in hardware. Most of the instruction set is implemented using microcode, which is low-level software
running inside the CPU that can specify how the circuitry is to be used, for each instruction. The built-in microcode
is part of the hardware, and read-only. Both the circuitry and the microcode can have bugs, which could cause reliability issues.
Microcode updates are proprietary blobs, uploaded to the CPU at boot time, which patches the built-in
microcode and disables buggy parts of the CPU to improve reliability. In the past, these updates were
handled by the operating system kernel, but on all recent systems it is the boot firmware that must perform this task.
Coreboot does distribute microcode updates for Intel and AMD CPUs, but libreboot cannot, because the whole point of libreboot
is to be 100% free software.
On some older Intel CPUs, it is possible to exclude the microcode updates and not have any reliability issues in practise.
All current libreboot systems work without microcode updates (otherwise, they wouldn't be supported in libreboot). However,
all modern Intel CPUs require the microcode updates, otherwise the system will not boot at all, or it will be extremely
unstable (memory corruption, for example).
Intel CPU microcode updates are signed, which means that you could not even run a modified version, even if
you had the source code. If you try to upload your own modified updates, the CPU will reject them. In other words,
the microcode updates are tivoized.
The microcode updates alter the way instructions behave on the CPU. That means they affect the way the CPU works, in
a very fundamental way. That makes it software. The updates are proprietary, and are software, so we exclude them from
libreboot. The microcode built into the CPU already is not so much of an issue, since we can't change it anyway (it's
read-only).
For years, coreboot has been struggling against Intel. Intel has been shown to be extremely uncooperative in general.
Many coreboot developers, and companies, have tried to get Intel to cooperate; namely, releasing source code
for the firmware components. Even Google, which sells millions of chromebooks (coreboot preinstalled)
have been unable to persuade them.
Even when Intel does cooperate, they still don't provide source code. They might provide limited information
(datasheets) under strict corporate NDA (non-disclosure agreement), but even that is not guaranteed. Even ODMs and IBVs can't
get source code from Intel, in most cases (they will just integrate the blobs that Intel provides).
Recent Intel graphics chipsets also require firmware blobs.
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 happens within Intel.
Basically, all Intel hardware from year 2010 and beyond will never be supported by libreboot. The libreboot project
is actively ignoring all modern Intel hardware at this point, and focusing on alternative platforms.
Back to top of page
Why is the latest AMD hardware unsupported in libreboot? #amd
It is extremely unlikely that any post-2013 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:
AMD Platform Security Processor (PSP) #amdpsp
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 16h +
systems (basically anything post-2013), and controls the main x86 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 x86 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 x86 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 (e.g. 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.
AMD IMC firmware #amdimc
Read https://www.coreboot.org/AMD_IMC.
AMD SMU firmware #amdsmu
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 F2A85-M) there were still other blobs present (Video BIOS, and others) preventing
the hardware from being supported in libreboot.
AMD AGESA firmware #amdagesa
This is responsible for virtually all core hardware initialization on modern AMD systems. In 2011,
AMD started cooperating with the coreboot project, releasing this as source code under a
free license. In 2014, they stopped releasing source code and started releasing AGESA
as binary blobs instead. This makes AGESA now equivalent to Intel FSP.
Read the Intel section #microcode. AMD's updates are 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) #amdbastards
AMD seemed like it was on the right track in 2011 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 x86 hardware newer
than the AMD Family 15h CPUs (on AMD's side) or anything post-2009 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.
Back to top of page
What *can* I use, then?
Libreboot has support for fam15h AMD hardware (~2012 gen) and some older Intel platforms (~2006-2009 gen).
We also have support for some ARM chipsets (rk3288). 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).
We're also interested in PowerPC (POWER8 and POWER9, or OpenPOWER) which Raptor Engineering Inc. is
looking into.
Check #compatibility for more information.
Will libreboot work on a ThinkPad T400 or T500 with an ATI GPU? #t400t500ati
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.
Back to top of page
Will the latest ThinkPad models be supported? #thinkpads
The latest ThinkPad generation supported in libreboot are the ones
using the GM45 (ICH9) chipsets, such as the ThinkPad X200 or T400.
ThinkPads newer than this generation will probably never be supported in libreboot,
due to the fact that there are signed blobs that cannot be removed or replaced
(e.g. Intel Management Engine). See #intel. Newer Lenovo laptops are
also starting to use the Intel Boot Guard, which specifically blocks the use of
firmware that has not been signed by the OEM.
Coreboot does have support for some more recent Lenovo laptops, but libreboot cannot support most of these.
Back to top of page
Will desktop/server hardware be supported? #desktops
Libreboot now supports desktop hardware: ../docs/hcl/index.html#supported_desktops_x86amdintel (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.
Back to top of page
Hi, I have <insert random system here>, is it supported? #randomhardware
Most likely not. First, you must consult coreboot's own hardware compatibility list
at http://www.coreboot.org/Supported_Motherboards and,
if it is supported, check whether it can run without any proprietary blobs in the ROM image. If it can: wonderful! Libreboot
can support it, and you can add support for it using the notes at ../docs/maintain/index.html.
If not, then you will need to figure out how to reverse engineer and replace (or remove) those blobs that do still exist, in such a way
where the system is still usable in some defined way.
For those systems where no coreboot support exists, you must first port it to coreboot and,
if it can then run without any blobs in the ROM image, it can be added to libreboot.
See: Motherboard Porting Guide (this is just the tip of the iceberg!)
Please note that board development should be done upstream (in coreboot) and merged downstream (into libreboot). This is
the correct way to do it, and it is how the libreboot project is coordinated so as to avoid too much forking of the
coreboot source code.
Back to top of page
What about ARM? #arm
Libreboot has support for some ARM based laptops, using the Rockchip RK3288 SoC.
Check the libreboot hardware compatibility list, for more information.
Back to top of page
Freedom questions
Are external GPUs (e.g. PCI-E) OK? #external-gpu
The Video BIOS is present on most video hardware. On all current libreboot systems, this is implemented using free software.
The Video BIOS is responsible for initializing any sort of visual display; without it, you'd have what's called
a headless system.
For integrated graphics, the VBIOS is usually embedded as an option ROM in the main boot firmware. For external
graphics, the VBIOS is usually on the graphics card itself. This is usually proprietary; the only difference is that
SeaBIOS executes it (alternatively, you embed it in a coreboot ROM image and have coreboot executes it, if you use
a different payload, such as GRUB).
We're going to tentatively say no, they're not OK. Unless you're actively working to replace the VBIOS, or find out how
to get a visual display without it (possible in some cases, if the kernel driver can be modified to work without it,
possibly only needing certain non-executable data).
Back to top of page
What other firmware exists outside of libreboot? #otherfirmware
The main freedom issue on any system, is the boot firmware (usually referred to as a BIOS or UEFI). Libreboot replaces the boot firmware
with fully free code, but even with libreboot, there may still be other hardware components in the system (e.g. laptop) that run
their own dedicated firmware, sometimes proprietary. These are on secondary processors, where the firmware is usually read-only, written for very specific tasks.
While these are unrelated to libreboot, technically speaking, it makes sense to document some of the issues here.
Note that these issues are not unique to libreboot systems. They apply universally, to most systems. The issues described below
are the most common (or otherwise critical).
Dealing with these problems will most likely be handled by a separate project.
EC (embedded controller) firmware #firmware-ec
Most (all?) laptops have this. The EC (embedded controller) is a small, separate processor that basically processes inputs/outputs
that are specific to laptops. For example:
-
When you flick the radio on/off switch, the EC will enable/disable the wireless devices (wifi, bluetooth, etc) and enable/disable
an LED that indicates whether it's turned on or not
-
Listen to another chip that produces temperature readings, adjusting fan speeds accordingly (or turning the fan(s) on/off).
-
Takes certain inputs from the keyboard, e.g. brightness up/down, volume up/down.
-
Detect when the lid is closed or opened, and send a signal indicating this.
-
Etc.
Alexander Couzens from coreboot (lynxis on coreboot IRC) is working on a free EC firmware replacement for the ThinkPads
that are supported in libreboot. See: https://github.com/lynxis/h8s-ec (not ready yet).
Most (all?) chromebooks have free EC firmware. Libreboot is currently looking into supporting a few ARM-based chromebooks.
EC is only present on laptops. On desktop/server boards it is absent (not required).
Back to top of page
HDDs and SSDs have firmware in them, intended to handle the internal workings of the device while exposing a simple,
standard interface (such as AHCI/SATA) that the OS software can use, generically. This firmware is transparent to the user
of the drive.
HDDs and SSDs are quite complex, and these days contain quite complex hardware which is even capable of running an entire
operating system (by this, we mean that the drive itself is capable of running its own embedded OS), even GNU/Linux
or BusyBox/Linux.
SSDs and HDDs are a special case, since they are persistent storage devices as well as computers.
Example attack that malicious firmware could do: substitute your SSH keys, allowing unauthorized remote access by an unknown
adversary. Or maybe substitute your GPG keys. SATA drives can also have DMA (through the controller), which means that they could read
from system memory; the drive can have its own hidden storage, theoretically, where it could read your LUKS keys and store them
unencrypted for future retrieval by an adversary.
With proper IOMMU and use of USB instead of SATA, it might be possible to mitigate any DMA-related issues that could arise.
Some proof of concepts have been demonstrated. For HDDs:
https://spritesmods.com/?art=hddhack&page=1
For SSDs:
http://www.bunniestudios.com/blog/?p=3554
Viable free replacement firmware is currently unknown to exist. For SSDs, the OpenSSD project may be interesting.
Apparently, SATA drives themselves don't have DMA but can make use of it through the controller.
This http://www.lttconn.com/res/lttconn/pdres/201005/20100521170123066.pdf (pages
388-414, 420-421, 427, 446-465, 492-522, 631-638) and this http://www.intel.co.uk/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1_3.pdf (pages 59, 67, 94, 99).
The following is based on discussion with Peter Stuge (CareBear\) in the coreboot IRC channel on Friday, 18 September 2015,
when investigating whether the SATA drive itself can make use of DMA. The following is based on the datasheets linked above:
<CareBear\> francis7 : so FIS type 39h is "DMA Activate FIS - Device to Host", which sounds interesting
<CareBear\> "transfer of data from the host to the device"
<CareBear\> "Upon receiving a DMA Activate, if the host adapter’s DMA controller has been programmed and armed, the host adapter shall initiate the transmission of a Data FIS and shall transmit in this FIS the data corresponding to the host memory regions indicated by the DMA controller’s context."
<CareBear\> FIS is a protocol unit, frame information structure
<CareBear\> so it seems that a drive can tell the host controller that it would like for DMA to happen, but actually unless the host software has already or will in the future set up this DMA transfer then nothing happens
<CareBear\> oh, but the drive can also send DMA Setup
<CareBear\>if a DMA Setup FIS is sent first, with the Auto-Activate bit set, then it is already set up, and the drive can initiate DMA
<CareBear\> "First party DMA is a superset capability not neccessarily supported by legacy mode devices or legacy mode device drivers but essential for accommodating future capabilities." translation: if the problem isn't already there it will be shortly
<CareBear\> "Upon receiving a DMA Setup, the receiver of the FIS shall validate the received DMA Setup request" - ie. the host is supposed to validate, but hey, maybe there's a bug there..
<CareBear\> "The specific implementation of the buffer identifier and buffer/address validation is not specified." - so noone will actually bother
<Basstard`> "the receiver of the FIS"
<CareBear\> in the case we're considering that's the host controller hardware in the chipset and/or the kernel driver
<CareBear\> most likely kernel driver
<CareBear\> francis7 : all SATA devices have flash-upgradeable firmware
That last part is important. The firmware can be upgraded from the OS.
<CareBear\> the harddrive is a nice computer-in-the-computer because it also has persistent storage
Regarding USB:
<CareBear\> then the attack surface becomes much smaller, but assuming a malicious harddrive then it can still try to get angry with the operating system
<CareBear\> a usb drive can e.g. send malformed USB descriptors (how the PS3 was broken)
(he's talking about so-called 'fuzzing' attacks)
Based on this, it's safe to say that use of USB instead of SATA is advisable if security is a concern. USB 2.0 has plenty of bandwidth for many HDDs (a few high-end ones
can use more bandwidth than USB 2.0 is capable of),
but for SSDs it might be problematic (unless you're using USB 3.0, which is not yet usable in freedom. See #firmware-usbhost).
Other links:
It is recommended that you use full disk encryption, on HDDs connected via USB. There are several adapters available
online, that allow you to connect SATA HDDs via USB. Libreboot documents how to install several GNU/Linux distributions
with full disk encryption. You can adapt these for use with USB drives:
The current theory (unproven) is that this will at least prevent malicious drives from wrongly manipulating data
being read from or written to the drive, since it can't access your LUKS key if it's only ever in RAM,
provided that the HDD doesn't have DMA (USB devices don't have DMA). The worst that it could do in this case
is destroy your data. Of course, you should make sure never to put any keyfiles in the LUKS header. Take what
this paragraph says with a pinch of salt. This is still under discussion, and none of this is proven.
Back to top of page
Ethernet NICs will typically run firmware inside, which is responsible for initializing the device internally.
Theoretically, it could be configured to drop packets, or even modify them.
With proper IOMMU, it might be possible to mitigate the DMA-related issues.
A USB NIC can also be used, which does not have DMA.
Back to top of page
Implements an instruction set. See #microcode for a brief description.
Here we mean microcode built in to the CPU. We are not talking about the updates supplied by the boot firmware
(libreboot does not include microcode updates, and only supports systems that will work without it)
Microcode can be very powerful. No proof that it's malicious, but it could theoretically
There isn't really a way to solve this, unless you use a CPU which does not have microcode.
(ARM CPUs don't, but most ARM systems require blobs for the graphics hardware at present, and typically
have other things like soldered wifi which might require blobs)
CPUs often on modern systems have a processor inside it for things like power management.
ARM for example, has lots of these.
Back to top of page
Sound hardware (integrated or discrete) typically has firmware on it (DSP) for processing input/output.
Again, a USB DAC is a good workaround.
Back to top of page
Webcams have firmware integrated into them that process the image input into the camera; adjusting focus,
white balancing and so on. Can use USB webcam hardware, to work around potential DMA issues; integrated webcams
(on laptops, for instance) are discouraged by the libreboot project.
Back to top of page
Doesn't really apply to current libreboot systems (none of them have USB 3.0 at the moment), but
USB 3.0 host controllers typically rely on firmware to implement the XHCI specification. Some newer
coreboot ports also require this blob, if you want to use USB 3.0.
This doesn't affect libreboot at the moment, because all current systems that are supported only
have older versions of USB available. USB devices also don't have DMA (but the USB host controller itself does).
With proper IOMMU, it might be possible to mitigate the DMA-related issues (with the host controller).
Back to top of page
Some laptops might have a simcard reader in them, with a card for handling WWAN, connecting to a 3g/4g (e.g. GSM) network.
This is the same technology used in mobile phones, for remote network access (e.g. internet).
NOTE: not to be confused with wifi. Wifi is a different technology, and entirely unrelated.
The baseband processor inside the WWAN chip will have its own embedded operating system, most likely proprietary. Use of this
technology also implies the same privacy issues as with mobile phones (remote tracking by the GSM network, by triangulating the signal).
On some laptops, these cards use USB (internally), so won't have DMA, but it's still a massive freedom and privacy issue.
If you have an internal WWAN chip/card, the libreboot project recommends that you disable and (ideally, if possible) physically
remove the hardware. If you absolutely must use this technology, an external USB dongle is much better because it can be
easily removed when you don't need it, thereby disabling any external entities from tracking your location.
Use of ethernet or wifi is recommended, as opposed to mobile networks, as these are generally much safer.
On all current libreboot laptops, it is possible to remove the WWAN card and sim card if it exists. The WWAN card is next to the wifi card, and the
sim card (if installed) will be in a slot underneath the battery, or next to the RAM.
Back to top of page
