update the policy page
parent
2b42e4c189
commit
71db2f2e70
|
@ -147,6 +147,101 @@ indeed critical, but again, currently outside the scope of what lbmk does.
|
||||||
At the moment, lbmk concerns itself just with coreboot, but this ought to
|
At the moment, lbmk concerns itself just with coreboot, but this ought to
|
||||||
change in the future.
|
change in the future.
|
||||||
|
|
||||||
|
Examples of FSF *sweeping blobs under the rug*
|
||||||
|
----------------------------------------------
|
||||||
|
|
||||||
|
Over the years, there have been numerous cases where the FSF actively fails to
|
||||||
|
provide incentive for levels of software freedom, such as:
|
||||||
|
|
||||||
|
* TALOS II "OpenPOWER" workstation from Raptor Engineering USA. It contains a
|
||||||
|
broadcom NIC inside it which requires firmware, and that firmware was non-free.
|
||||||
|
The FSF were willing to ignore it, and certify the TALOS II product under RYF,
|
||||||
|
but Timothy Pearson of Raptor Engineering had it freed anyway, without being
|
||||||
|
told to. Hugo Landau reverse engineered the specification and Evan Lojewski
|
||||||
|
wrote a free driver. See:
|
||||||
|
See: <https://www.devever.net/~hl/ortega> and <https://github.com/meklort/bcm5719-fw>
|
||||||
|
* FSF once endorsed the ThinkPad X200, as sold by [Minifree Ltd](https://minifree.org),
|
||||||
|
which contains the Intel ME; the bootrom is still there, as is the ME
|
||||||
|
coprocessor, but the ME is put into a disabled state via the Intel Flash
|
||||||
|
Descriptor, and the ME firmware in flash is removed. However, the ME is an
|
||||||
|
entire coprocessor which, with free firmware, could be used for a great many
|
||||||
|
things. In the Libreboot and coreboot projects, there has always been interest
|
||||||
|
in this but the FSF disregards it entirely. The X200 product they certified
|
||||||
|
came with Libreboot pre-installed.
|
||||||
|
* Libreboot has a utility written by I, Leah Rowe, that generates ICH9M flash
|
||||||
|
descriptors and GbE NVM images from scratch. This is necessary to configure
|
||||||
|
the machine, but these are binary blobs otherwise; the FSF would have been
|
||||||
|
quite content to certify the hardware anyway since these were non-software
|
||||||
|
blobs in a format fully documented by Intel (they are just binary configuration
|
||||||
|
files), but I went ahead and wrote ich9gen anyway. With ich9gen, you can
|
||||||
|
more easily modify the descriptor/gbe regions for your firmware image. See:
|
||||||
|
<https://libreboot.org/docs/install/ich9utils.html> - osboot also has this
|
||||||
|
* FSF once endorsed the ThinkPad T400 with Libreboot, as sold by Minifree. This
|
||||||
|
machine comes in two versions: with ATI+Intel GPU, or only Intel GPU. If ATI
|
||||||
|
GPU, it's possible to configure the machine so that either GPU is used. If the
|
||||||
|
ATI GPU is to be used, a firmware blob is needed for initialization, though the
|
||||||
|
driver for it is completely free. FSF ignored this fact and endorsed the
|
||||||
|
hardware, so long as Libreboot does not enable the ATI GPU or tell people how
|
||||||
|
to enable it. The *Intel* GPU on that machine has free initialization code by
|
||||||
|
the coreboot project, and a fully free driver in both Linux and BSD kernels.
|
||||||
|
In the configuration provided by Libreboot, the ATI GPU is completely disabled
|
||||||
|
and powered down.
|
||||||
|
* All Libreboot-compatible ThinkPads contain non-free Embedded Controller
|
||||||
|
firmware, which is user-flashable (*and intended for update by the
|
||||||
|
manufacturer*). The FSF chose to ignore the EC firmware, under
|
||||||
|
their *secondary processor* exemption. See:
|
||||||
|
<http://libreboot.localhost/faq.html#ec-embedded-controller-firmware>
|
||||||
|
|
||||||
|
In all of the above cases, the FSF could have been stricter, and bolder, by
|
||||||
|
insisting that these *additional* problems for freedom were solved. They did
|
||||||
|
not. There are many other examples of this, but the purpose of this article is
|
||||||
|
not to list all of them (otherwise, a book could be written on the subject).
|
||||||
|
|
||||||
|
Problems with FSDG
|
||||||
|
------------------
|
||||||
|
|
||||||
|
The FSDG criteria is separate from RYF, but has similar problems. FSDG is
|
||||||
|
what the FSF-endorsed GNU+Linux distros comply with. Thoughts:
|
||||||
|
|
||||||
|
* Excluding firmware blobs in the linux kernel is *bad*. Non-free firmware
|
||||||
|
is *also bad*. Including them is a wiser choice, if strong education is also
|
||||||
|
provided about *why they are bad* (lack of freedom). If you expose them to
|
||||||
|
the user, and tell them about it, there is greater incentive (by simple
|
||||||
|
reminder of their existence) to reverse engineer and replace them.
|
||||||
|
* Firmware *in your OS kernel* is *good*. The FSF simultaneously gives the OK
|
||||||
|
for hardware *with those same firmware blobs* if the firmware is embedded
|
||||||
|
into a ROM/flash chip on the device, or embedded in some processor. If the
|
||||||
|
firmware is on separate ROM/flash, it could still be replaced by the user via
|
||||||
|
reverse engineering, but then you would probably have to do some soldering
|
||||||
|
(replace the chip on the card/device). *If the firmware is loaded by the
|
||||||
|
OS kernel, then the firmware is exposed to the user and it can be more
|
||||||
|
easily replaced. FSF criteria in this regard encourages hardware designers
|
||||||
|
to hide the firmware instead, making actual freedom less likely!*
|
||||||
|
|
||||||
|
Besides this, FSDG seems OK. Any free operating system should ideally not
|
||||||
|
have non-free *drivers* or *applications*.
|
||||||
|
|
||||||
|
Hardware manufacturers like to shove everything into firmware because their
|
||||||
|
product is often poorly designed, so they later want to provide workarounds in
|
||||||
|
firmware to fix issues. In many cases, a device will already have firmware on it
|
||||||
|
but require an update supplied to it by your OS kernel.
|
||||||
|
|
||||||
|
The most common example of non-free firmware in Linux is for wifi devices.
|
||||||
|
This is an interesting use-case scenario, if freed, because it could be used
|
||||||
|
for owner-controlled *software defined radio*.
|
||||||
|
|
||||||
|
The *Debian* way is ideal. The Debian GNU+Linux distribution is entirely free
|
||||||
|
by default, and lacks any of the non-free firmware, but they have a separate
|
||||||
|
repository containing non-free software. If you only want firmware, it is
|
||||||
|
trivial to get installer images with it included, or add that to your installed
|
||||||
|
system.
|
||||||
|
|
||||||
|
*Banning* linux-firmware specifically is a threat to freedom in the long term,
|
||||||
|
because new users of GNU+Linux might be discouraged from using the OS if their
|
||||||
|
hardware doesn't work. You might say: just buy new hardware! This is often not
|
||||||
|
possible for users, and the user might not have the skill to reverse engineer
|
||||||
|
it either.
|
||||||
|
|
||||||
More detailed insight about microcode
|
More detailed insight about microcode
|
||||||
=====================================
|
=====================================
|
||||||
|
|
||||||
|
@ -336,3 +431,28 @@ software!
|
||||||
|
|
||||||
In the year 2022 onwards, we can do better. The RYF program should be cancelled.
|
In the year 2022 onwards, we can do better. The RYF program should be cancelled.
|
||||||
It is no longer fit for purpose.
|
It is no longer fit for purpose.
|
||||||
|
|
||||||
|
Other resources
|
||||||
|
===============
|
||||||
|
|
||||||
|
Hector Martin, leader of the *Asahi Linux* project (for booting linux kernels
|
||||||
|
on M1 macbooks) wrote a very robust twitter thread criticizing the RYF criteria
|
||||||
|
and much of what he wrote inspired *this* article that you are reading. See:
|
||||||
|
|
||||||
|
<https://twitter.com/marcan42/status/1040626210999431168>
|
||||||
|
|
||||||
|
If you wish to avoid non-free javascript, you can read this thread using
|
||||||
|
nitter:
|
||||||
|
|
||||||
|
<https://nitter.net/marcan42/status/1040626210999431168>
|
||||||
|
|
||||||
|
Article updates
|
||||||
|
===============
|
||||||
|
|
||||||
|
This article was updated on 21 January 2022, to add the section with examples
|
||||||
|
in the real world of FSF sweeping blobs under the rug (ATI T400 thinkpads,
|
||||||
|
ICH9M descriptors and TALOS II NIC firmware).
|
||||||
|
|
||||||
|
Also on 21 January 2022: added section about FSDG (criticisms of it).
|
||||||
|
|
||||||
|
Also on 21 January 2022: added link to Hector Martin's twitter thread.
|
||||||
|
|
Loading…
Reference in New Issue