guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Free firmware - A redefinition of the term and a new metric for it's mea


From: David Craven
Subject: Free firmware - A redefinition of the term and a new metric for it's measurement.
Date: Fri, 3 Feb 2017 15:37:32 +0100

Motivation:
We want to be able to exercise our freedoms in all parts of our
computing systems. This leads to the benefits of higher security and
maintaining hardware devices after their end of life.

Background:
All peripheral devices work roughly the same.

Host Controller Interface <-> Link Layer <-> Physical Layer

The physical layer is a mixed signal circuit responsible for
implementing the electrical interface of the device. The boundary
between LL and PHY is a clock domain crossing. The PHY layer is
implemented entirely in hardware and is fixed in silicone.

The link layer is implemented either in digital logic also fixed in
silicone or in complex peripherals partially in firmware.

HCI <-> Microcontroller <-> Digital logic <-> PHY

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.

2. The peripheral contains persistent storage containing the firmware
and uses a separate interface for flashing the firmware.

Problem:
Today as an example, a WiFi card using option 2 is considered more
free than one using option 1.

Implications on Security:
While in the first case we can check the hash of the binary blob and
be certain that the binary blob we are providing is what is running on
the device, in the second case we do not even have that guarantee. A
malicious party can reflash the firmware and no one would ever know.
Security through obscurity is no security at all.

Just as important a threat to security as a malicious party is human
error. With the second model there is no simple way to fix
vulnerabilities even if the vendor is aware and willing to fix it.

Implications on Freedom:
This also makes it much harder to write, debug and distribute free
firmware if such where available.

Solution:
We need to encourage and allow option 1 as opposed to option 2.
Hardware suggestions by the FSF should instead of focusing on a black
and white - needs binary blobs or does not need binary blobs - focus
on the following:

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.

2. The firmware can be loaded using the standard kernel api and the
device does not contain any internal storage.

3. There is documentation available that enables the developement of
free firmware.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]