code:
% Guidelines for Good Conduct

Our Pledge
----------

In the interest of fostering an open and welcoming environment, we as
contributors and maintainers wish that participation in our project and our
community will be a harassment-free experience for everyone, regardless of age,
body size, disability, ethnicity, gender identity and expression, level of
experience, nationality, personal appearance, race, religion, or sexual identity
and orientation.

Our Standards
-------------

Examples of behavior that contributes to creating a positive environment
include:

* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
  address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
  professional setting

Our Responsibilities
--------------------

Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to these conduct guidelines, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.

Scope
-----

These conduct guidelines apply both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.

Specifically, in normal circumstances, the scope of these guidelines apply
directly to:

* The IRC channel and mailing lists
* The subreddit (r/libreboot on reddit.com)
* The notabug instance (at <https://notabug.org/libreboot>), which also
  includes bug reports and code review
* The contents of any contributions to Libreboot, including commits to the Git
  repository

Other communications channels are unofficial, and not part of the Libreboot
project.

Complaints
----------

All complaints will be reviewed and investigated and will result in a response
that is deemed necessary and appropriate to the circumstances. The project team
is obligated to maintain confidentiality with regard to the reporter of an
incident. Further details of specific enforcement policies may be posted
separately.

Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting one of the moderators privately via IRC private message
(see list below):

* Andrew Robbins: **and\_who** on Freenode, email
  [andrew@libreboot.org](mailto:andrew@libreboot.org)
* Leah Rowe: **unoccupied** on Freenode, email
  [leah@libreboot.org](mailto:leah@libreboot.org)
* Paul Kocialkowski: **paulk-X** Freenode (X is variable, for this
  person, email [paul@libreboot.org](mailto:paul@libreboot.org)
  check in the channel)
* Swift Geek: **swiftgeek** on Freenode, email
  [swiftgeek@libreboot.org](mailto:swiftgeek@libreboot.org)

If the complaint is for abuses on the Libreboot subreddit at
[r/libreboot](https://www.reddit.com/r/libreboot/) then there are a separate
group of moderators whom you can contact, via private message on the Reddit
website. The subreddit has a public list of moderators on it.

If you deviate from these guidelines, make sure that it is with good reason.
Treatment of each case will be handled pragmatically, on a case-by-case basis.

These are guidelines, and are not set in stone. We, as moderators, may choose
to enforce or not enforce these guidelines, in whole or in part, at our own
discretion. We are, after all, only human ourselves and we sometimes make
mistakes.

Attribution
-----------

These guidelines are adapted from the
[Contributor Covenant](http://contributor-covenant.org/), version 1.4,
available at <http://contributor-covenant.org/version/1/4>

The Contributor Covenant is made available under [Creative Commons Attribution
4.0 International Public License](https://creativecommons.org/licenses/by/4.0/)

External links
--------------

[Contributor Covenant homepage](http://contributor-covenant.org)             --
[version that this is based on](http://contributor-covenant.org/version/1/4/)


code:
---
title: Project contributors
...

If we forgot to mention you here, let us know and we'll add you. (or if
you don't want to be mentioned, let us know and we'll remove your
entry)

Alyssa Rosenzweig
-----------------

Switched the website to use markdown in lieu of handwritten HTML and custom
PHP. Additionally assisted with [booting
Linux](https://blog.rosenzweig.io/blobless-linux-on-the-pi.md) on the Raspberry
Pi without blobs. Current sysadmin and assists with project management.

Andrew Robbins
--------------

Works on large parts of Libreboot's build system and related documentation.
Andrew joined the Libreboot project as part of core management on 4 June 2017.
IRC nick `and_who` on #libreboot IRC.

Arthur Heymans
--------------

Merged a patch from coreboot into libreboot, enabling C3 and C4 power
states to work correctly on GM45 laptops. This was a long-standing issue
before Athur's contribution. Arthur also fixed VRAM size on i945 on
GM45 systems, allowing maximum VRAM allocation for the onboard GPUs on
these systems, another longstanding issue in libreboot. Contact **apvh**
in the \#libreboot IRC channel.

Damien Zammit
-------------

Maintains the Gigabyte GA-G41M-ES2L coreboot port, which is integrated
in libreboot. Also works on other hardware for the benefit of the
libreboot project. Contact **damo22** on the freenode IRC network. This
person's website is [zammit.org](http://www.zammit.org/).

Denis Carikli
-------------

Based on the work done by Peter Stuge, Vladimir Serbineko and others in
the coreboot project, got native graphics initialization to work on the
ThinkPad X60, allowing it to be supported in libreboot. Denis gave
a lot of advice and helped found the libreboot project. Contact
**GNUtoo-irssi** in the \#libreboot IRC channel. Denis is also one of
the founders of the [Replicant](http://replicant.us/) project.

Jeroen Quint
------------

Contributed several fixes to the libreboot documentation, relating to
installing Parabola with full disk encryption on libreboot systems.
Contact **Jezza** in the \#libreboot IRC channel.

Klemens Nanni
-------------

Made many fixes and improvements to the GRUB configuration used in
libreboot, and several tweaks to the build system. Contact **kl3** in
the \#libreboot IRC channel.

Leah Rowe
---------

Founder of the Libreboot project, and a current maintainer.

Leah is also responsible for [vimuser.org](https://vimuser.org/)
(personal website) and [transit.org.uk](https://transit.org.uk/)
(support group for transgender people).

Marcus Moeller
--------------

Made the libreboot logo.

Patrick "P. J." McDermott
---------------------------

Patrick also did a lot of research and wrote the libreboot FAQ section
relating to the [Intel Management Engine](../faq.md#intelme), in addition
to making several improvements to the build system in libreboot.

Paul Kocialkowski
-----------------

Ported the ARM (Rockchip RK3288 SoC) based *Chromebook* laptops to
libreboot. Also one of the main [Replicant](http://www.replicant.us/)
developers. Contact Paul on the libreboot IRC channel by the alias
**paulk** or **paulk-<hostname>** (hostname is variable).

Paul Menzel
-----------

Investigated and fixed a bug in coreboot on the ThinkPad X60/T60 exposed
by Linux kernel 3.12 and up, which caused 3D acceleration to stop
working and video generally to become unstable. Paul worked with Libreboot on
this, sending patches to test periodically until the bug was fixed
in coreboot, and then helped her integrate the fix in libreboot. Contact
**PaulePanter** in the \#libreboot IRC channel.

Peter Stuge
-----------

Helped write the [FAQ section about DMA](../faq.md#hddssd-firmware), and provided
general advice in early days of the project. Contact **CareBear\\** in
the \#coreboot IRC channel on freenode.

Steve Shenton
-------------

Ported the ThinkPad X200 to libreboot, by figuring out how to deactive
the Intel Management Engine on that laptop, and remove the firmware
while still making the system boot correctly. The ThinkPad T400, T500,
R400 and R500 were also ported to libreboot, based on this work.

Swift Geek
----------

Contributed a patch for ich9gen to generate 16MiB descriptors. Contact
**swiftgeek** in the IRC channel.

Timothy Pearson
---------------

Ported the ASUS KGPE-D16 board to coreboot for the company Raptor
Engineering of which Timothy is the CEO.
Timothy maintains this code in coreboot,
helping the project with the libreboot integration for it. This person's
contact details are on the raptor site, or you can ping **tpearson** on
the freenode IRC network.

Vladimir Serbinenko
-------------------

Ported many of the thinkpads supported in libreboot, to coreboot, and
made many fixes in coreboot which benefited the libreboot project.
Contact **phcoder** in the \#coreboot IRC channel on freenode.

Zyliwax
-------------------

Wrote the grubeditor.sh script and associated documentation. Contact
**zyliwax** in the \#libreboot channel.

license: mit


code:
---
title: Downloads
...

**The latest stable release is 20160907, released on 2016-09-07 and can
be found at [\#https](#https).**

Information about specific changes in each Libreboot release, can be found
at [docs/release.md](docs/release.md)

If you're more interested in libreboot development, go to the
[libreboot development page](../git.md), which also includes links to the
Git repositories.

GPG signing key
---------------

Releases are signed with GPG.

    gpg --recv-keys 0x969A979505E8C5B2

Full key fingerprint: CDC9 CAE3 2CB4 B7FC 84FD  C804 969A 9795 05E8 C5B2

The GPG key can also be downloaded with this exported dump of the
pubkey: [lbkey.asc](lbkey.asc).

    $ sha512sum -c sha512sum.txt
    $ gpg --verify sha512sum.txt.sig

Do you have a mirror?
---------------------

Let us know! We will add it here.

If you wish to create a new mirror of the Libreboot releases, you can use
*rsync*. See: [rsync mirror list](#rsync).

HTTPS mirrors {#https}
-------------

These mirrors are recommended, since they use TLS (https://) encryption.

<https://www.mirrorservice.org/sites/libreboot.org/release/> (University
of Kent, UK)

<https://mirror.math.princeton.edu/pub/libreboot/> (Princeton
university, USA)

<https://mirror.splentity.com/libreboot/> (Splentity Software, USA)

<https://mirror.sugol.org/libreboot/> (sugol.org)
(formerly nephelai.zanity.net/mirror/libreboot)

<https://elgrande74.net/libreboot/> (elgrande74.net, France)

<https://mirror.koddos.net/libreboot/> (koddos.net, Netherlands)

<https://mirror.swordarmor.fr/libreboot/> (swordarmor.fr, France)

<https://mirror-hk.koddos.net/libreboot/> (koddos.net, Hong Kong)

<https://mirror.cyberbits.eu/libreboot/> (cyberbits.eu, France)

RSYNC mirrors {#rsync}
-------------

Useful for mirroring Libreboot's entire set of release archives. You can put
an rsync command into crontab and pull the files into a directory on your
web server.

*It is highly recommended that you use the libreboot.org mirror*, if you wish
to host an official mirror. Otherwise, if you simply want to create your own
local mirror, you should use one of the other mirrors, which sync from
libreboot.org.

<rsync://rsync.libreboot.org/mirrormirror/> (Libreboot project official mirror)

<rsync://rsync.mirrorservice.org/libreboot.org/release/> (University of Kent,
UK)

<rsync://mirror.math.princeton.edu/pub/libreboot/> (Princeton university, USA)

<rsync://ftp.linux.ro/libreboot/> (linux.ro, Romania)

<rsync://mirror.koddos.net/libreboot/> (koddos.net, Netherlands)

<rsync://mirror-hk.koddos.net/libreboot/> (koddos.net, Hong Kong)

Are you running a mirror? Contact the libreboot project, and the link will be
added to this page!

HTTP mirrors {#http}
------------

WARNING: these mirrors are non-HTTPS which means that they are
unencrypted. Your traffic could be subject to interference by
adversaries. Make especially sure to check the GPG signatures, assuming
that you have the right key. Of course, you should do this anyway, even
if using HTTPS.

<http://mirrors.mit.edu/libreboot/> (MIT university, USA)

<http://mirror.linux.ro/libreboot/> (linux.ro, Romania)

<http://mirror.helium.in-berlin.de/libreboot/> (in-berlin.de, Germany)

<http://mirror.cyberbits.eu/libreboot/> (cyberbits.eu, France)

FTP mirrors {#ftp}
-----------

WARNING: FTP is also unencrypted, like HTTP. The same risks are present.

<ftp://ftp.mirrorservice.org/sites/libreboot.org/release/> (University
of Kent, UK)

<ftp://ftp.linux.ro/libreboot/> (linux.ro, Romania)

Statically linked
------------------

Libreboot includes statically linked executables. If you need the
sources for those statically linked dependencies inside the executables,
then you can contact the libreboot project using the details on the home
page; source code will be provided. You can download this source code
from [the "ccsource" directory](ccsource/) on libreboot.org.


code:
---
title: Frequently Asked Questions
x-toc-enable: true
...

Important issues
================

Is the Libreboot project still active?
-------------------------------------------

Yes! The [git repository](https://notabug.org/libreboot/libreboot) shows all of
the work that we're currently doing. Libreboot is quite active.

So when is the next version of Libreboot coming out?
-------------------------------------------------------

Short answer: It's out when it's out. If you want to help out and submit
patches, refer to [the Git page](git.md).

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.
- 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](docs/install/)
- 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.

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](git.md) for instructions on submitting patches to the
  documentation.
- Encourage companies, or any persons with the skills/resources, to get
  involved with Libreboot development.

What version of libreboot do I have?
----------------------------------------------------------------

See "Version" [in the documentation](../docs/#version)

Flashrom complains about DEVMEM access
--------------------------------------

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-r1955 on Linux 4.11.9-1-ARCH (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Calibrating delay loop... OK.
Error accessing high tables, 0x100000 bytes at 0x000000007fb5d000
/dev/mem mmap failed: Operation not permitted
Failed getting access to coreboot high tables.
Error accessing DMI Table, 0x1000 bytes at 0x000000007fb27000
/dev/mem mmap failed: Operation not permitted
```

The backlight is darker on the left side of the screen when lowering the brightness on my X200/T400/T500/R400
---------------------------------------------------------------------------------------------------------------

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](../docs/misc/#finetune-backlight-control-on-intel-gpus).

The ethernet doesn't work on my X200/T400/X60/T60 when I plug in it
-------------------------------------------------------------------

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-D16 doesn't boot with the PIKE2008 module installed
-----------------------------------------------------------------------

Libreboot 20160818, 20160902 and 20160907 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
practise, though, they are usually non-free.

Loading the option ROM from the PIKE2008 module on either ASUS KCMA-D8
or KGPE-D16 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 PIKE2008
module without loading the option ROM.

Libreboot-unstable (or git) now disables loading PCI option ROMs, but
previous releases with SeaGRUB (20160818-20160907) 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?
-----------------------------------------------------------------------

You can safely ignore those errors, they exist because we can't quiet down
cryptomount command from `for` loop in libreboot's
[grub.cfg](https://notabug.org/libreboot/libreboot/src/r20160907/resources/grub/config/menuentries/common.cfg#L66).
It could be fixed in upstream grub by contributing patch that would add
quiet flag to it.

How to save kernel panic logs on thinkpad laptops?
--------------------------------------------------

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$`):

1.  Start a listener server on the target machine (netcat works well):

    `target$ nc -u -l -p 6666`

2.  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`

3.  find source's ethernet interface name, it should be of the form `enp*` or
    `eth*`, see `ip address` or `ifconfig` output.

    `source# iface="enp0s29f8u1"` change this

    Fill the target machine's IPv4 address here:

    `source# tgtip="192.168.1.2"` change this

3.  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`

4.  Change console loglevel to debugging:

    `source# dmesg -n debug`

5.  Test if the logging works by e.g. 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.

6.  Try to reproduce the kernel panic.

Machine check exceptions on some Montevina (Penryn CPU) laptops
---------------------------------------------------------------

Some GM45 laptops have been freezing or experiencing a kernel panic
(blinking caps lock LED and totaly unresponsive machine, sometimes followed
by an automatic reboot within 30 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:

- [T400 Machine check: Processor context corrupt](https://notabug.org/libreboot/libreboot/issues/493)
- [X200 Machine check: Processor context corrupt](https://notabug.org/libreboot/libreboot/issues/289)

- [Unrelated, RAM incompatibility and suspend-to-ram issues on X200](https://libreboot.org/docs/hardware/x200.html#ram_s3_microcode)

Hardware compatibility
======================

What systems are compatible with libreboot?
-----------------------------------------------------------------------------------

See the [hardware compatibility list](docs/hardware/).

Will the Purism laptops be supported?
----------------------------------------------------------------------

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](#intelme)
- [More freedom issues on modern Intel hardware](#intel)

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? {#intel}
-----------------------------------------------------------

It is 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](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Known_vulnerabilities_and_exploits)***,
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](https://mjg59.dreamwidth.org/33981.md) 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](https://defectivebydesign.org/what_is_drm_digital_restrictions_management)***
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](../docs/hardware/gm45_remove_me.md) on
the Intel 4 Series systems that it supports, such as the [Libreboot
X200](../docs/install/x200_external.md) and [Libreboot
T400](../docs/install/t400_external.md). 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 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](http://me.bios.io/Main_Page),
[unhuffme](http://io.netgarage.org/me/), [coreboot
wiki](http://www.coreboot.org/Intel_Management_Engine), and
[Wikipedia](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology).
The book ***[Platform Embedded Security Technology
Revealed](https://www.apress.com/9781430265719)*** 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/2016/11/17/neutralize_ME_firmware_on_sandybridge_and_ivybridge.html>

Also see (effort to disable the ME):
<https://www.coreboot.org/pipermail/coreboot/2016-November/082331.html>
- look at the whole thread

### 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](https://www.gnu.org/philosophy/free-sw.html).

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.

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).

### Intel is uncooperative

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](https://01.org/linuxgraphics/intel-linux-graphics-firmwares?langredirect=1).

Intel is [only going to get
worse](https://www.phoronix.com/scan.php?page=news_item&px=Intel-Gfx-GuC-SLPC)
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](https://www.gnu.org/philosophy/free-sw.html) 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.**

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:

[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-libre.md)

### AMD Platform Security Processor (PSP)

This is basically AMD's own version of the [Intel Management
Engine](#intelme). 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

Read <https://www.coreboot.org/AMD_IMC>.

### AMD SMU firmware

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](https://media.ccc.de/v/31c3_-_6103_-_en_-_saal_2_-_201412272145_-_amd_x86_smu_firmware_analysis_-_rudolf_marek),
and based on this work, Damien Zammit (another coreboot hacker)
[partially replaced it](https://github.com/zamaudio/smutool/) 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

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](#fsp).

### AMD CPU microcode updates

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)

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.

What *can* I use, then? {#whatcaniuse}
-------------------------

Libreboot has support for fam15h AMD hardware (~2012 gen) and some
older Intel platforms like Napa, Montevina, Eagle Lake, Lakeport (2004-2006).
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).

Will libreboot work on a ThinkPad T400 or T500 with an ATI GPU?
---------------------------------------------------------------------------------------------------

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?
------------------------------------------------------------------------

Libreboot now supports desktop hardware:
[(see list)](../docs/hardware/#supported_desktops_x86/intel)
(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 <insert random system here>, is it supported?
--------------------------------------------------------------------------------------------------------

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](http://www.coreboot.org/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.

What about ARM?
-----------------------------------

Libreboot has support for some ARM based laptops, using the *Rockchip
RK3288* SoC. Check the libreboot [hardware compatibility
list](../docs/hardware/#supported_list), for more information.

General questions
=================

How do I install libreboot?
-------------------------------------------------------

See [installation guide](docs/install/)

How do I program an SPI flash chip?
---------------------------------------------------------------------------------

SPI flash chips can be programmed with the [BeagleBone
Black](../docs/install/bbb_setup.md) or the [Raspberry
Pi](../docs/install/rpi_setup.md).

It's possible to use a 16-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?
-------------------------------------------------------------------

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)](../docs/gnulinux/encrypted_debian.md)
and
[(Installing Parabola or Arch GNU+Linux-Libre, with FDE)](../docs/gnulinux/encrypted_parabola.md)

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 GM45
laptops (e.g. ThinkPad X200, T400), you can write-protect (see
[ICH9 gen utility](../docs/hardware/gm45_remove_me.html#ich9gen)).

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?
------------------------------------------------------------------------

Libreboot actually uses the [GRUB
payload](http://www.coreboot.org/GRUB2). More information about payloads
can be found at
[coreboot.org/Payloads](http://www.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 practise, 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?
---------------------------------------------------------------------------------------------------

Libreboot integrates the GRUB bootloader already, as a
*[payload](http://www.coreboot.org/Payloads)*. 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](../docs/gnulinux/grub_boot_installer.md)

Do I need to re-flash when I re-install a distribution?
-------------------------------------------------------------------------------------------

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](../docs/gnulinux/grub_cbfs.md)

What does a flash chip look like?
-----------------------------------------------------------------

SOIC-8 SPI flash chip:

![SOIT-8 SPI flash chip](images/soic8.jpg)

SOIC-16 SPI flash chip:

![SOIT-8 SPI flash chip](images/soic16.jpg)

Who did the logo?
----------------------------------------------------------------

See the [license information](logo/license.md).

The Libreboot logo is available as a [bitmap](logo/logo.png), a
[vector](logo/logo.svg), or a [greyscale vector](logo/logo_grey.svg).

Libreboot Inside stickers are available as a
[PDF](logo/stickers/libreboot-inside-simple-bold-1.60cmx2.00cm-diecut-3.pdf) or
a
[vector](logo/stickers/libreboot-inside-simple-bold-1.60cmx2.00cm-diecut-3.svg)

What other firmware exists outside of libreboot?
==================================================

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.

### External GPUs

The Video BIOS is present on most video cards. For integrated graphics,
the VBIOS (special kind of OptionROM) is usually embedded
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 can execute it (alternatively, you embed it
in a coreboot ROM image and have coreboot executes it, if you use a
different payload, such as GRUB).

On current libreboot systems, instead of VBIOS, coreboot native GPU init is used,
which is currently only implemented for Intel GPUs.
Other cards with proper KMS drivers can be initialized once Linux boots,
but copy of VBIOS may be still needed to fetch proper VRAM frequency
and other similar parameters (without executing VBIOS code).

In configurations where SeaBIOS and native GPU init are used together,
a special shim VBIOS is added that uses coreboot linear framebuffer.

### EC (embedded controller) firmware

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 present on nearly all laptops. Other devices use, depending on complexity,
either EC or variant with firmware in Mask ROM - SuperIO.

### HDD/SSD firmware

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](http://www.openssd-project.org/wiki/The_OpenSSD_Project)
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:

According to those linked documents, FIS type 39h is *"DMA Activate FIS
- Device to Host"*. It mentions *"transfer of data from the host to
the device, and goes on to say: 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."* FIS is a protocol unit (Frame
Information Structure). Based on this, it seems that a drive can tell
the host controller that it would like for DMA to happen, but unless the
host software has already or will in the future set up this DMA transfer
then nothing happens. **A drive can also send DMA Setup**. 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. The document goes on to
say *"Upon receiving a DMA Setup, the receiver of the FIS shall
validate the received DMA Setup request."* - in other words, the host
is supposed to validate; but maybe there's a bug there. The document
goes on to say *"The specific implementation of the buffer identifier
and buffer/address validation is not specified"* - so noone will
actually bother. *"the receiver of the FIS"* - in the case we're
considering, that's the host controller hardware in the chipset and/or
the kernel driver (most likely the kernel driver). All SATA devices have
flash-upgradeable firmware, which can usually be updated by running
software in your operating system; **malicious software running as root
could update this firmware, or the firmware could already be
malicious**. Your HDD or SSD is the perfect place for a malicious
adversary to install malware, because it's a persistent storage device
as well as a computer.

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

Use of USB is also not an absolute guarantee of safety, so do beware.
The attack surface becomes much smaller, but a malicious drive could
still attempt a "fuzzing" attack (e.g. sending malformed USB
descriptors, which is how the tyrant DRM on the Playstation 3 was
broken, so that users could run their own operating system and run
unsigned code). (you're probably safe, unless there's a security flaw
in the USB library/driver that your OS uses. USB is generally considered
one of the safest protocols, precisely because USB devices have no DMA)

Other links:

-   <http://motherboard.vice.com/read/the-nsas-undetectable-hard-drive-hack-was-first-demonstrated-a-year-ago>

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
distributions with full disk encryption. You can adapt these for use
with USB drives:

-   [Full disk encryption with Debian](../docs/gnulinux/encrypted_debian.md)
-   [Full disk encryption with Parabola](../docs/gnulinux/encrypted_parabola.md)

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.**

### NIC (ethernet controller)

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.

### CPU microcode

Implements an instruction set. See
description. Here we mean microcode built in to the CPU. We are not
talking about the updates supplied by the boot firmware (libreboot does
not include microcode updates, and only supports systems that will work
without it) Microcode can be very powerful. No proof that it's
malicious, but it could theoretically

There isn't really a way to solve this, unless you use a CPU which does
not have microcode. (ARM CPUs don't, but most ARM systems require blobs
for the graphics hardware at present, and typically have other things
like soldered wifi which might require blobs)

CPUs often on modern systems have a processor inside it for things like
power management. ARM for example, has lots of these.

### Sound card

Sound hardware (integrated or discrete) typically has firmware on it
(DSP) for processing input/output. Again, a USB DAC is a good
workaround.

### Webcam

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.

### USB host controller

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).

### WWAN firmware

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.

Operating Systems
=================

Can I use GNU+Linux?
--------------------------------------------------

Absolutely! It is well-tested in libreboot, and highly recommended. See
[installing GNU+Linux](../docs/gnulinux/grub_boot_installer.md) and
[booting GNU+Linux](../docs/gnulinux/grub_cbfs.md).

Any recent distribution should work, as long as it uses KMS (kernel mode
setting) for the graphics.

Fedora won't boot? (may also be applicable to Redhat/CentOS)
-----------------------------------------------------------

On Fedora, by default the grub.cfg tries to boot linux in 16-bit mode. You
just have to modify Fedora's GRUB configuration.
Refer to [the GNU+Linux page](docs/gnulinux/index.md#fedora-wont-boot).

Can I use BSD?
----------------------------------

Absolutely! Libreboot has native support for NetBSD, OpenBSD and LibertyBSD.
Other distros are untested.

See:
[docs/bsd/](docs/bsd/)

Are other operating systems compatible?
-------------------------------------------------------------------

Unknown. Probably not.

Where can I learn more about electronics
==========================================

* Basics of soldering and rework by PACE
    Both series of videos are mandatory regardless of your soldering skill.
    * [Basic Soldering](https://www.youtube.com/watch?v=vIT4ra6Mo0s&list=PL926EC0F1F93C1837)
    * [Rework and Repair](https://www.youtube.com/watch?v=HKX-GBe_lUI&list=PL958FF32927823D12)
* [edX course on basics of electronics](https://www.edx.org/course/circuits-electronics-1-basic-circuit-mitx-6-002-1x-0)
    In most countries contents of this course is covered during
    middle and high school. It will also serve well to refresh your memory
    if you haven't used that knowledge ever since.
* Impedance intro
    * [Similiarities of Wave Behavior](https://www.youtube.com/watch?v=DovunOxlY1k)
    * [Reflections in tranmission line](https://www.youtube.com/watch?v=y8GMH7vMAsQ)
    * Stubs:
        * [Wikipedia article on stubs](https://en.wikipedia.org/wiki/Stub_(electronics))
        * [Polar Instruments article on stubs](http://www.polarinstruments.com/support/si/AP8166.html)
        With external SPI flashing we only care about unintended PCB stubs
* Other YouTube channels with useful content about electronics
    * [EEVblog](https://www.youtube.com/channel/UC2DjFE7Xf11URZqWBigcVOQ)
    * [Louis Rossmann](https://www.youtube.com/channel/UCl2mFZoRqjw_ELax4Yisf6w)
    * [mikeselectricstuff](https://www.youtube.com/channel/UCcs0ZkP_as4PpHDhFcmCHyA)
    * [bigclive](https://www.youtube.com/channel/UCtM5z2gkrGRuWd0JQMx76qA)
    * [ElectroBOOM](https://www.youtube.com/channel/UCJ0-OtVpF0wOKEqT2Z1HEtA)
    * [Jeri Ellsworth](https://www.youtube.com/user/jeriellsworth/playlists)
* Boardview files can be open with [OpenBoardview](https://github.com/OpenBoardView/OpenBoardView),
which is free software under MIT license.

Use of youtube-dl with mpv would be recommended for youtube links

Lastly the most important message to everybody gaining this wonderful new hobby - [Secret to Learning Electronics](https://www.youtube.com/watch?v=xhQ7d3BK3KQ)


code:
**[Edit this page](/git.md#editing-the-website-and-documentation-wiki-style)** --
[License](/docs/fdl-1.3.md)                 --
[Template](/license.md)                     --
[Authors](/contrib.md)                      --
[Conduct Guidelines](/conduct.md)           --
[Governance](/management.md)                --
[Peers Community](https://peers.community/)


code:
---
title: Information about sending patches for review
x-toc-enable: true
...

Download Libreboot from the Git repository like so:

    $ git clone https://notabug.org/libreboot/libreboot.git

You can submit your patches via
[Notabug pull requests](#how-to-submit-your-patches-via-pull-requests).

Information about how the Libreboot project is governed is documented in our
[general management guidelines](management.md).

Libreboot development is done using the Git version control system.
Refer to the [official Git documentation](https://git-scm.com/doc) if you don't
know how to use Git.

Editing the website and documentation, wiki-style
-------------------------------------------------

The website and documentation is inside the `www` directory in the
[Git repository](#how-to-download-libreboot-from-the-git-repository), in
Pandoc flavoured Markdown. The website is generated into static HTML via Pandoc
with the following scripts in that directory:

- index.sh: generates the news feed (on the News section of the website)
- publish.sh: converts an .md file to an .html file
- Makefile: with calls to index.sh and publish.sh, compiles the entire
  Libreboot website

Use any standard text editor (e.g. Vim, Emacs, Nano, Gedit) to edit the files,
commit the changes and
[send patches](#how-to-submit-your-patches-via-pull-requests).

Optionally, you can install a web server (e.g. lighttpd, nginx) locally and
set the document root to the *www* directory in your local Git repository.
With this configuration, you can then generate your local version of the
website and view it by typing `localhost` in your browser's URL bar.

Privacy of contributors (you do not have to reveal your name or identity!)
-------------------------------------------------------------------------

Contributions that you make are publicly recorded, in a Git repository which
everyone can access. This includes the name and email address of the
contributor.

In Git, for author name and email address, you do not have to use identifying
data. You can use Libreboot Contributor and your email address could be
specified as contributor@libreboot.org. You are permitted to do this, if
you wish to maintain privacy. We believe in privacy. If you choose to remain
anonymous, we will honour this.

Of course, you can use whichever name and/or email address you like.

For enhanced privacy, we recommend that you use a [trustworthy VPN
provider](https://torrentfreak.com/which-vpn-services-keep-you-anonymous-in-2019/)
and route all of your traffic through Tor (on top of the VPN). The
[Tor website](https://torproject.org/) has instructions on it for routing
traffic through the Tor network.

Legally speaking, all copyright is automatic under the Berne Convention of
international copyright law. It does not matter which name, or indeed whether
you even declare a copyright (but we do require that certain copyright
licenses are used - read more about that on this same page).

If you use a different name and email address on your commits/patches, then you
should be fairly anonymous. Use
[git log](https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History)
and [git show](https://git-scm.com/docs/git-show) to confirm that before you
push changes to a public Git repository.

General guidelines for submitting patches
-----------------------------------------

We require all patches to be submitted under a free license:
<https://www.gnu.org/licenses/license-list.html>.

- GNU General Public License v3 is highly recommended
- For documentation, we require GNU Free Documentation License v1.3 or higher

*Always* declare a license on your work! Not declaring a license means that
the default, restrictive copyright laws apply, which would make your work
non-free.

GNU+Linux is generally recommended as the OS of choice, for Libreboot
development.

General code review guidelines
------------------------------

Any member of the public can
[submit a patch](#how-to-submit-your-patches-via-pull-requests).
Members with push access must *never* push directly to the master branch;
issue a Pull Request, and wait for someone else to merge. Never merge your own
work!

Your patch will be reviewed for quality assurance, and merged if accepted.

How to download Libreboot from the Git repository
-------------------------------------------------

In your terminal:

    $ git clone https://notabug.org/libreboot/libreboot.git

A new directory named `libreboot` will have been created, containing
libreboot.

How to submit your patches (via pull requests)
----------------------------------------------

Make an account on <https://notabug.org/> and navigate (while logged in) to
<https://notabug.org/libreboot/libreboot>. Click *Fork* and in your account,
you will have your own repository of Libreboot. Clone your repository, make
whatever changes you like to it and then push to your repository, in your
account on NotABug.

Now, navigate to <https://notabug.org/libreboot/libreboot/pulls> and click
*New Pull Request*.

You can submit your patches there. Alternative, you can log onto the Libreboot
IRC channel and notify the channel of which patches you want reviewed, if you
have your own Git repository with the patches.

Once you have issued a Pull Request, the Libreboot maintainers will be notified
via email. If you do not receive a fast enough response from the project, then
you could also notify the project via the #libreboot channel on Freenode.


code:
html {
    background-color: #eee;
}

body {
    background-color: #fff;
    margin: 0 auto;
    max-width: 60em;
    padding: 0.2em 1em;
    box-shadow: 0 0 6px;
}

body {
    line-height: 1.6;
    font-family: Cantarell, sans-serif;
    font-size: 1.1em;
    color: #222;
}

pre {
    padding: 0.3em;
}

pre,table {
    overflow-x: auto;
    display: block;
}

code, pre {
    background-color: #DDD;
}

img {
    max-width: 100%;
}

#logo {
    width: 20%;
    float: right;
}

a {
    text-decoration: none;
    color: #22D;
}

/* probably generated with autolink_bare_uris extension */
a.uri {
    word-wrap: break-word;
}

a:hover {
    color: #008;
}

.date {
    display: block;
}

h1, h2, h3, .h:hover a {
    display: inline;
}

.h a {
    display: none;
}


code:
---
title: Libreboot
...

[![Libreboot logo](logo/logo.svg "Canteloupe, the libreboot
mascot"){#logo}](faq.md#who-did-the-logo)

[FAQ](faq.md)                                                               --
[Download](download.md)                                                     --
[Install](docs/install/)                                                    --
[Documentation](docs/)                                                      --
[News](news/)                                                               --
[Chat](https://webchat.freenode.net/?channels=libreboot)                    --
[Bugs](https://notabug.org/libreboot/libreboot/issues)                      --
[Send patches](git.md)                                                      --
[Buy preinstalled](suppliers.md)

Libreboot is [freedom-respecting](https://www.gnu.org/philosophy/free-sw.html)
*boot firmware*, initialising the hardware and booting an operating system.
This replaces the proprietary BIOS/UEFI boot firmware found in computers.
Libreboot is compatible with [certain computers that have
been ported to](docs/hardware/) on ARM and x86.

*Boot firmware* is the low-level software in a computer, which executes the
moment that computer is turned on. It brings all of the components (CPU,
[memory controller](https://en.wikipedia.org/wiki/Memory_controller),
some peripherals and so on) into a useable state so that it can easily run
software. The boot firmware will typically load an *operating system*
(GNU+Linux, BSD, etc) which provides a common interface for application
software to make use of hardware in the computer. In addition to Libreboot, we
also recommend the use of a freedom respecting operating system as defined
by the [GNU Free System Distribution
Guidelines](https://gnu.org/distros/free-system-distribution-guidelines.html)
(so, no Windows/Mac. Use GNU+Linux!)

Combined, the boot firmware and operating system provide a unified interface
which makes computers functional whether for day to day usage or software
development.

Libreboot's main upstream provider is [coreboot](https://www.coreboot.org/),
from which we [remove binary blobs](docs/#about-the-libreboot-project).
We upstream our custom patches to projects like coreboot,
depthcharge, GRUB, and flashrom where possible. Together, our build system
and documentation is provided with the aim of making free boot firmware
accessible to all. *In other words, Libreboot is a coreboot distribution!* Put
simply, Libreboot integrates all of the required software components into a
single unified package that is applicable to most use-case scenarios.

We provide user support via [\#libreboot
IRC](https://webchat.freenode.net/?channels=libreboot) on Freenode. Development
discussion also occurs on IRC. Instructions for sending patches are
on the [git](git.md) page.

Why use Libreboot?
------------------

Did you know you have rights? The right to privacy, freedom of thought, freedom
of speech and the right to read. In the context of computing, that means anyone
can use [free software](https://www.gnu.org/philosophy/free-sw.html). Simply
speaking, free software is software that is under the direct sovereignty of the
user and, more importantly, the collective that is the *community*. Non-free
software (e.g. Windows, MacOS or proprietary BIOS/UEFI) is under the exclusive
control of its owners, not users! With freedom-respecting software, the users
can at any time study the source code, and even become developers themselves!
Want to help the cause? Some ways you can contribute might be to write
documentation, provide user support, or test others' contributions. Need more
ideas on how you can help with the project? See [the git page](git.md). If you
would like a specific feature developed but you are not technically inclined,
you can hire anybody you would like to do the work for you. With free software,
you are essentially the owner of your own copy which is why it's free (as in
freedom).

Many people use [non-free](https://www.gnu.org/philosophy/proprietary.html)
proprietary boot firmware, even if they use GNU+Linux. Non-free BIOS/UEFI
firmware often [contains](faq.md#intel) [backdoors](faq.md#amd), can be slow
and have severe bugs. Development and support can be abandoned at any time.
By contrast, libreboot is fully free software, where anyone can contribute or
inspect its code. Libreboot is not simply free software; it is also
[copyleft](http://www.gnu.org/philosophy/copyleft.html) software, released
under (for the most part) a mixture of
[GNU General Public License v2 and v3](http://www.gnu.org/licenses/gpl.html).
This means that the software will always be *free* for everyone. If someone
were to take Libreboot and try to make it proprietary, they'd be *breaking the
law*. In other words, copyleft ensures a public *commons* where all knowledge
and power is shared without discrimination.

Libreboot is faster, more secure and more reliable than most non-free
firmware. Libreboot provides many advanced features, like encrypted
/boot/, GPG signature checking before booting a Linux kernel and more!


code:
#!/usr/bin/env bash
#
# Copyright (C) 2017 Alyssa Rosenzweig <alyssa@rosenzweig.io>
# Copyright (C) 2017 Michael Reed <michael@michaelreed.io>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

BLOGTITLE="Libreboot News"
BLOGBASE="https://libreboot.org/"
BLOGDESCRIPTION="News on Libreboot development"

# MANIFEST determines the order of news articles in news/index.md
FILES=$(< news/MANIFEST)

# usage: title file
title() {
    sed -n 1p "$1" | sed -e s-^..--
}

# usage: meta file
meta() {
    file=$1
    URL=$(printf '%s\n' "${file%.md}.html" | sed -e s-news/--)

    printf '%s\n' "[$(title "$file")]($URL){.title}"
    printf '%s\n' "[$(sed -n 3p "$file" | sed -e s-^..--)]{.date}"
    printf '\n'
    tail -n +5 "$file" | perl -p0e 's/(\.|\?|\!)( |\n)(.|\n)*/.../g'

    printf '\n'
    printf '\n'
}

# usage: rss_header
rss_header() {
    printf '%s\n' '<rss version="2.0">'
    printf '%s\n' '<channel>'

    printf '%s\n' "<title>$BLOGTITLE</title>"
    printf '%s\n' "<link>${BLOGBASE}news/</link>"
    printf '%s\n' "<description>$BLOGDESCRIPTION</description>"
}

# usage: rss_main file
rss_main() {
    file=$1

    # render content and escape
    desc=$(sed -e 's/</\</g' "${file%.md}.bare.html" | sed -e 's/>/\>/g')
    url="${file%.md}.html"

    printf '%s\n' '<item>'
    printf '%s\n' "<title>$(title "$file")</title>"
    printf '%s\n' "<link>$BLOGBASE$url</link>"
    printf '%s\n' "<description>$desc</description>"
    printf '%s\n' '</item>'
}

# usage: rss_footer
rss_footer() {
    printf '%s\n' '</channel>'
    printf '%s\n' '</rss>'
}

# generate the index file
cat news-list.md > news/index.md
for f in $FILES
do
    meta "$f" >> news/index.md
done

# generate the RSS index
rss_header > news/feed.xml
for f in $FILES
do
    rss_main "$f" >> news/feed.xml
done
rss_footer >> news/feed.xml

cp news/feed.xml feed.xml


code:
---
title: General management guidelines
x-toc-enable: true
...

This document defines the nature of Libreboot's leadership structure.

Democratic governance of the Libreboot project
----------------------------------------------

In principle and in practise, Libreboot is a collectively and democratically
governed project. Any member of the public can propose anything. Our leadership
is a flat hierarchy; we have no leader!

Our core management team is open to the public; anyone can join it, if they
make substantial contributions to the project and if the current core
management team agrees. Libreboot is a *community* project.

All proposals, big or small, should be discussed and (if approved by core
management) implemented.

Information about code review can be found [on the Git section of the
website](git.md#general-code-review-guidelines).

List of members in the core management team
-------------------------------------------

In alphabetical order:

- Andrew Robbins is a core developer. IRC nick **and\_who**, email
  [andrew@libreboot.org](mailto:andrew@libreboot.org)
- Paul Kocialkowski is a core developer. IRC nick **paulk-X**
  (**X** is variable, and changes over time), email
  [paul@libreboot.org](mailto:paul@libreboot.org)
- Leah Rowe is a core developer (and project founder). IRC nick
  **unoccupied**, email [leah@libreboot.org](mailto:leah@libreboot.org)
- Swift Geek is a core developer. IRC nick **swiftgeek**, email
  [swiftgeek@libreboot.org](mailto:swiftgeek@libreboot.org)

Generally, the people on this list have these responsibilities:

- Code review (they have merge rights on the Git repositories)
- Voting rights on all major decisions, with community input.
- System administration (where necessary) for Libreboot's infrastructure.
- Moderation of the IRC channel, mailing lists and other discussion mediums.
- Comply with the [Guidelines for Good Conduct](conduct.md)

All members are granted SSH access, with varying levels of access depending on
need. At the very least, all members are able to update the website when new
changes to it are merged in the Git repository.

People of interest
------------------

These people are not part of core management, but still have influence.

Other IRC channel moderators:

- IRC nick **specing** on the Libreboot IRC channel.

specing occasionally provides assistance, and moderates the IRC channel.

Additionally, Libreboot has a separate set of operators on the subreddit
r/libreboot. Check Reddit for more information. Actions taken by moderators
there are also subject to these management guidelines.


code:
% News announcements from the Libreboot project

Updates to libreboot, both technical and organisational, will be written about
here over time. Subscribe to [RSS](/feed.xml) for notifications.

-------------------------------------------------------------------------------


code:
news/libreplanet2019-workshop.md
news/freenode2018-workshop.md
news/leah-fundraiser.md
news/libreplanet2018-workshop.md
news/release-testing-20171221.md
news/lenovo-recall.md
news/alyssa-resignation.md
news/talos.md
news/new-mailing-lists.md
news/andrew-robbins-new-maintainer.md
news/formalised-structure.md
news/proposal-rejoin-gnu.md
news/unity.md

path: www/news/MANIFEST


code:
% Alyssa Rosenzweig has resigned from the Libreboot project
% Leah Rowe
% 1 September 2017

Alyssa Rosenzweig has notified the rest of the team (Andrew Robbins, Paul
Kocialkowski, Leah Rowe and Swift Geek) of her intention to step down from the
core management team, as per [our management guidelines](../management.md),
due to increased pressure from school studies which prevent her from having
time to contribute.

In her email, she wishes the Libreboot project well and states that she intends
to continue contributing in the future.

I, Leah Rowe, wish Alyssa all the best in life, and I'm sure that this will be
felt by the other maintainers in Libreboot, and I'm extremely grateful for the
numerous invaluable contributions that she made to the project.

A note about the hosting infrastructure, and sysadmin tasks
-----------------------------------------------------------

Alyssa was previously acting as the system administrator for the Libreboot
project, in charge of maintaining the project's infrastructure. Additionally,
she was acting as Public Relations manager for the project; in particular, she
was handling Libreboot's application to join the GNU project.

I have since assumed these responsibilities, at least for the time being, and
I will be working alongside the other members of the team going forward.
Since Alyssa had stepped down, nobody was in place to maintain the hosting
infrastructure for the project. Our old hosting provider was giving us issues,
so we switched hosting provider; this means that I'm currently maintaining the
hosting infrastructure for the project, since nobody else was willing to.

The only piece of infrastructure currently missing is the mailing list. We now
have a fully functional mail server, and I will finish studying and installing
GNU Mailman version 3 (the software that will be used for handling the mailing
list). There are currently no repositories available for it on the GNU+Linux
distribution that libreboot.org uses (Debian), so we will have to maintain it
ourselves.

Swift Geek also works alongside me, for sysadmin tasks, and has been
particularly helpful in advising on good practises for the setup of the new
mail server. I myself haven't had time to work on it for a while, but it will
be up soon. The mailing list that Alyssa created was only online for a week,
before we had to switch hosting provider for the project, and nobody had
started using it yet, so downtime for the mailing list hasn't been a huge
issue; people use the Notabug instance, and IRC.

I will issue another news post, once the new mailing list is online. For the
time being, the links to it have been removed on the website.

The mail server itself is online, so the 4 of us on the team now have
libreboot.org email addresses; these are published on the
[governance page](../management.md). If anyone wishes to contact a member of
the project directly via email, we recommend that you use these email
addresses.

Of interest: the new hosting infrastructure for libreboot.org is entirely
libre. The main router on that network is a Libreboot system, with the router software
running on top of GNU+Linux. The server for libreboot.org (web and mail server)
is also a Libreboot system with GNU+Linux; postfix and dovecot for the mail
server, and nginx for the web server. DNS is also planned (the DNS hosting is
currently outsourced).

Of further interest: libreboot.org is now IPv6-ready. All services are
dual stack IPv4+IPv6. Stronger encryption is used in the TLS configuration for
nginx aswell, for HTTPS, and HSTS is enabled by default.

The certificate authority used for TLS is Let's Encrypt. This is used for
HTTPS and for encrypted connections to the mail server.

The new hosting infrastructure is also much more secure than the previous one,
not just because Libreboot powers it but because of special configurations made
on externally accessible services (such as SSH and email).

I am currently looking for a new colocation provider, but the hardware used
for hosting should be stable from now on. I have found one, which I'm looking
into, but I'm also considering other options.


code:
% Welcoming Andrew Robbins
% Leah Rowe and Alyssa Rosenzweig
% 4 Jun 2017

On 25 April, Libreboot adopted new [collective governance
policies](../management.md), creating a flat-hierarchy leadership of four
people. As a result, all patches are reviewed, and all major decisions are
voted on by the maintainers with community input. These policies formalise our
democratic standards.

Today, we welcome Andrew Robbins (IRC nick `and_who` and
[NotABug](https://notabug.org) user [and_who](https://notabug.org/and_who)) as
our first new maintainer under the new policy. Going forward, Andrew will gain
push access to Libreboot in order to review patches, as well as voting rights
and IRC operator status.

Andrew works on critical improvements to the build system, many of which have
already been merged. He is passionate about Libreboot, understanding the
project at a deep level, and he has been an active member of the community.
Thus, with unanimous agreement from the existing maintainers, Andrew has joined
the project officially.

We look forward to Andrew's next contributions as our project continues to
grow.

The new list of maintainers is as follows:

- Alyssa Rosenzweig
- Andrew Robbins
- Leah Rowe
- Paul Kocialkowski
- Swift Geek


code:
% Formalising Democracy
% Alyssa Rosenzweig
% 25 Apr 2017

One month ago, the [Open Letter to the Free Software Community](/news/unity.md)
was published, alluding to the new Libreboot leadership. Today, the ideals
expressed there have been formalised into an official project policy. In the
new [General Management Guidelines](/management.md), the ins-and-outs of our
democratic system is codified, including the formal team list. Hint, hint: the
structure isn't "I, Alyssa Rosenzweig, decide everything and Thou shall bow
down to me"! There are four core team members, and we welcome community
feedback for major decisions.

There was an underlying tension in the letter: should Libreboot rejoin GNU? On
purely political and technical levels, the answer is a resounding "yes". We
share the mission of spreading free software. Our communities overlap. Most of
the Libreboot community uses GNU software, and much of GNU uses libreboot.
Technically, the tighter integration is useful. Politically, closer ties will
strengthen both of our projects. But this is neither completely a political or
technical question -- it is a human one.

There is no easy answer to this. But the best course of action is to reach out
beyond the team to the community at large. A number of people ranging from
Libreboot users to GNU developers to casual bystanders chimed in, and the
answer was an overwhelming "yes, you should have done this a month ago!"

With that in mind, we have reapplied for GNU. Leah conducted the initial
discussions, such as the Reddit thread, as she felt that she needed to correct
her own error. I have since been handling the application itself, which was
submitted recently. GNU has not yet made a decision on the matter. Ultimately,
it will be up to Richard Stallman himself whether the mutual benefits of
joining will outweigh any potential awkwardness.

No matter the response, Libreboot remains committed to free software. Whether
or not we need a g'new name, this will never change.


code:
% Libreboot workshop at Freenode #live 2018 Conference in Bristol, UK
% Leah Rowe
% 2 November 2018

Freenode #live is the annual conference held by
[Freenode](https://freenode.net/) in Bristol, UK. This year I, Leah Rowe, will
be there doing a talk about Libreboot at 10AM (UTC +0) on November 3rd. In
addition, I have decided (hence this announcement) at the last minute that I'm
taking my SPI flashing equipment with me. More details about this conference
are on the Freenode #live website: <https://freenode.live/>

If anyone attending this conference wants their system flashed with Libreboot,
bring it to the conference. I'll be volunteering at the FSF booth there all
day on both Saturday and Sunday.

I will also be representing the FSF as a volunteer on both days.


code:
% Help Leah, founder of Libreboot, get Gender Reassignment Surgery
% Leah Rowe
% 19 April 2018

I spoke with Andrew Robbins and Swift Geek on #libreboot IRC. These are two
other members of the core Libreboot community. This news post was submitted to
Pull Request, subject to their approval before publishing on libreboot.org.

My name is Leah Rowe, and I'm the founder of the Libreboot project. I’m a 26
year old British trans woman, living in the UK. After a lifetime of
repression and denial, I came out as transgender in June 2016; I
began living full-time as my true self for the first time. This was my coming
out message to the Libreboot community:
<https://lists.nongnu.org/archive/html/libreboot/2016-05/msg00004.html>

I need help from the community in order to to pay for my Gender Reassignment
Surgery. Here is my fundraiser:
<https://vimuser.org/surgery/>

I'm unable to pay for it myself. 2 years ago, I paid 90,000 USD to Raptor
Engineering to port the ASUS KGPE-D16 and KCMA-D8 to Libreboot as well as 4000
AUD to Damien Zammit for the Gigabyte GA-G41M-ES2L and Intel D510MO ports.
Besides this, I've spent huge amounts of money in general on development of my
own and I've dedicated countless hours to this project. I love Libreboot
and I love working on it. For instance, I ported the ThinkPad X200 (later T400,
T500 etc) to Libreboot myself, working alongside Steve Shenton to free it from
the Intel ME firmware. Unfortunately, this has left me severely out of pocket
and, even now, I can't afford to pay for the things I need for myself such as
this.

As a direct result of my contributions, the Free Software community is in a
much better state than it was.
The [Free Software Foundation](https://www.fsf.org/) now hosts fsf.org and
[gnu.org](https://www.gnu.org/), as well as
[GNU Savannah](https://savannah.gnu.org/) (used by many GNU projects, for code
hosting and collaboration) on ASUS KGPE-D16
servers, running Libreboot. Additionally, both the Free Software Foundation and
[Software Freedom Conservancy](https://sfconservancy.org/) use Libreboot laptops
almost exclusively in their offices. Thousands of people now use Libreboot.
Projects inspired by Libreboot have also appeared such as the
[TALOS II workstation](https://www.raptorcs.com/TALOSII/).

I greatly appreciate any help that the community can give me, no matter how
big or small. It will mean a great deal to me, and allow me to focus on my
passions, including Libreboot.


code:
% Lenovo Battery Recall for ThinkPad Laptops
% Johnny Rasnic
% 14 September 2017

[On 21 April 2015, Lenovo expanded a recall on Lenovo batteries found in ThinkPad models.](https://pcsupport.lenovo.com/cr/en/solutions/hf004122)
Libreboot-supported laptops that may be affected by this are the X200 and X200S.
To find out if you are affected, use [this Lenovo tool.](https://lenovobattery2014.orderz.com/)
Lenovo advises that owners of the recalled models "should turn off the system, remove the battery,
and only power your ThinkPad by plugging in the AC adapter and power cord."
Upon battery verification, Lenovo will replace recalled batteries free of charge.
Battery replacement instructions for the X200/X200s are found [on this page.](https://pcsupport.lenovo.com/cr/en/parts/pd003507/)