Re: Free firmware - A redefinition of the term and a new metric for it's measurement.

[Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>]

On Fri, 3 Feb 2017 15:37:32 +0100
David Craven <david@craven.ch> wrote:

> This leads to two models of loading the firmware that runs on the MCU.
> 
> 1. The peripheral does not contain persistent storage and the firmware
> is loaded by the linux kernel through a standard API.
When using the Linux kernel, the firmwares are sometimes loaded by
something else than the linux kernel:
- In most Replicant devices, the modem firmware is in a separate eMMC
  partition in the device(Smartphone/Tablet), and it is loaded by
  libsamsung-ipc.
- Some bootloaders such as u-boot have the ability to load some
  firmwares or FPGA bitstreams.

> 2. The peripheral contains persistent storage containing the firmware
> and uses a separate interface for flashing the firmware.
This doesn't differenciate between a chip with internal
non-voltaile memory, and a chip with external (potentially shared)
flash chip.

This can have some serious freedom privacy and security implications
when the peripheral's firmware is on the same flash chip than the OS
(GNU/Linux or Android/Replicant). In that case the processor running
that non-free firmware can also access the OS partition.

I think it is the case on some older qualcomm devices like the HTC
Dream, where the modem firmware is on the same flash chip than the
Android Operating system...

On samsung smartphones and tablets supported by recent Replicant
versions, libsamsung-ipc, which is a library that talks to the modem,
loads the modem firmware. Thanks to that hardware architecture, the
modem doesn't have access to the eMMC that holds the Android
distribution (here Replicant).

> Problem:
> Today as an example, a WiFi card using option 2 is considered more
> free than one using option 1.
I understand the point, but let's approach the issue from another point
of view to better understand its contradictions and the tradeoffs that
have been made.

Let's take it from a top-down perspective where the top is application
software that runs on top of lower level software. Down goes deep down
in the hardware, like down to how a resistor is made.

If applications have to be free software (It's morally wrong not to
respect the users freedom), the software that makes the hardware works
also needs to be free software:
- For the same reasons than applications have to be free software.
- Since that software is more privileged it's very useful and important
  for it to be free software.
- As you stated it also impacts the ability to use hardware beyond
  their end of life, which reduces waiste.

Given the above one might wonder how deep we should go down and what is
the fronteer between hardware and software.

Given that even hardware and chip design has freedom privacy and
security inplications it is desirable to have freedom there too.
However given that we are not there I think that we need to have some
criterias that are reachable.

One can for instance use a computer that respects the FSF RYF criterias
as of today. I am for instance using one to write this mail.
My computer is not ideal though since:
- Its hard disk has a non-free firmware
- Its embedded controller has a non-free firmware

Beside the fact that I added the tor-browser, all rest is RYF and FSDG
compliant.

The question for me is then how to use the acceptable/not-acceptable
line to get more freedom out of it:
- If redistributing (and using) non-free firmwares was:
  - still acceptable
  - not an issue in the FSDG guidelines
  - done in the FSDG compliant distributions 
  Then we would probably:
  - Not have had the ath9k_htc firmware liberated (thanks to
    Thinkpenguin,Atheros and the people who made it possible) 
  - May have more people using FSDG compliant distributions.

Having the ath9k_htc firmware liberated was really really important,
especially because:
- The Intel WiFi cards present in many laptops require non-free
  firmware to work, at least with recent kernels.
- Many laptop boot-firwmare(BIOS, UEFI) will refuse to boot if the user
  either changed the wifi card like with the default BIOS of the Lenovo
  Thinkpad X60 and X200, or removed it like with at least one of the HP
  Envy laptops.
- The ath9k_htc compatible cards can still be bought and found and have
  been for a long time.
- The ath9k_htc compatible cards supports modern-enough WiFi standards.

With that we can still use WiFi by ignoring the intel wifi card and
using an USB wifi card instead.

There are also free software firmware to support some other peripherals
such as:
- Old b43 compatible wifi cards (OpenFWWF).
- keyspan compatible devices.
- Older atheros based USB wifi cards.
- Probably few other devices.

While this is really great and that each new free firmware is a great
achievement and is really important, they are also crucial because we
failed:
- ATI GPUs are almost unusable with free software, in the best case we
  can load the radeon driver but do not have 3D accelerations and many
  of the features of that driver working because of the lack of a free
  firmware.
- Intel WiFi cards are a pain, the user has to go buy new USB WiFi
  cards.

I think that the solution is not to make the use and redistribution of
such non-free firmwares okay, instead we should find way to make some
people work to replace them with free software:
- Intel WiFi Cards: The idea if and which ones can work without a
  non-free firmware. The easiest way to do it is to:
  1) Look in h-node which intel WiFi cards work
  2) Try to reproduce it and make them work with the same setup
  3) Try to understand why they work
  4) Try to forward-port what makes them work in recent linux-libre and
     send the patch upstream, to linux-libre (or linux if applicable).
- Radeon GPUs: The people working on porting GNU/Linux to the Sony
  Playstation 4 have tools to work with radeon firmwares, and probably
  enough understanding and documentation to be able to create free
  software firmwares: https://github.com/fail0verflow/radeon-tools.git

Theses are not the only hardware-related issues with reguard to free
software, however they impact *a lot* of people, directly if they use
FSDG distributions and harve hardware not supported by free software
because of non-free firmwares, or indirectly because they cannot use
such hardware or distributions.

> Implications on Security:
[...]
Hardware design also has huge implications on security. Some busses
allow access to the RAM used by the main processor, which holds the
linux kenrel and other programs being executed...
Preventing peripherals to access all of the memory is possible but
depends on a lot of factors.
With the PCI and derivated busses to work we need the following:
- In the case of x86 computers, the hardware has to have an IOMMU, and
  that IOMMU has not to be flawed to allow PCI devices to bypass it.
- The operating system needs to configure the IOMMU correctly.
- In the case of AMD devices, the boot firmware(BIOS/UEFI) needs to
  have IVRS ACPI tables that contains part of the configuration of the
  IOMMU.
- If the devices are enabled at boot, the boot firmware needs to setup
  the IOMMU before the RAM is initialized and accesible to the
  devices on the PCI/PCIe bus.

To get more information on the availability of such feature on common
computers, see https://www.qubes-os.org/hcl/

When taking security seriously, the fact that a non-free firmware is
running in peripherals that can have access to the main system's RAM
has to be taken into account.

However I don't have a clear idea on whether it has to be dealt with
within free software policies or not, and how much it is in the scope
of free software.

I don't think we, as the free software community, can ignore it as it
means that some non-free code can take control of your computer...

For instance in Replicant, we decided not to focus on devices that can
permit non-free firmwares to take control of the main processor, and
instead to prioritize work on devices where the hardware doesn't have
any physical ways to allow a non-free firmware to access the main
processor's RAM.

Even if I disagree with your suggestion below, as I think it might not
be the best strategy, I'll give some input nevertheless.

For me the best strategy would be to have some people work on the
technical issues not to have to adjust policies backward and allow more
and more non-free software.
If we have enough free firmwares, many GNU/Linux distributions may
consider getting rid of non-free firmwares entierely.
Making loadable and non-loadable firmwares policies consistent would
then makes a lot of sense as it would probably have a good impact on
freedom. We might also be able to leverage loadable firmwares code to
make other peripherals with non-loadable-by-a-host-computer firmwares
work.

> 1. The firmware is freely redistributeable - allowing free software
> distributions to redistribute the firmware as opposed to the user
> having to download the firmware themselves and accept arbitrary terms
> and conditions.
Freely redistributable firmwares often have conditions that I find
unacceptable. The validity of such conditions then depends on the
jurisdiction you live in.
Many have no-modification and no-reverse-engineering clauses.

> 2. The firmware can be loaded using the standard kernel api and the
> device does not contain any internal storage.
You might want to consider the following alternative:
- The firmware can be loaded using free software and the device does
  not contain any internal storage.
- The firmware can be loaded using free software and the device does
  not contain any internal storage for code.
- The firmware can be loaded using free software and the device does
  not contain any internal storage that can be used for other purposes
  than storing documented configuration data.
The last two alternatives contains takes into account the storage of
data such as the MAC Address and calibration data of network devices.

> 3. There is documentation available that enables the developement of
> free firmware.
- There is sufficent documentation available to permit the development
  of a free firmware.
- There is sufficent documentation available to permit the development
  of a free firmware, and to be able to understand the
  freedom/security/privacy implication of that hardware.

The later might be interesting to:
- Make sure that an IOMMU works correctly.
- Have an idea of what the management engine bootrom does.
- Have an idea of what a CPU does to the data during context switch.
- Have an idea of the risk associated with the use of a network
  interface chip like the Intel e1000e:
  - Where is a firmware supposed to be stored, can you be sure that the
    card runs no firmware?
  - What a remote computer might be able to do to the chip?
- Know if an external pc-card can access your main processor's RAM if
  you didn't load drivers that enable it.
- Know which peripherals or busses have access to your RAM while your
  operating system is not started yet.
- Know if a bus or device allow DMA:
  - Make sure that a superIO doesn't allow DMA access to the main
    processor's RAM in the dock connector of a laptop.
  - Make sure that the PCI lanes aren't exported on a dock connector of
    a laptop.

Denis.