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

[Ivan Zaigralin]

I think FSF has struck gold with its firmware stance, basically treating it as 
all other software, which it is. So the question of what constitutes libre 
firmware is not controversial: can we read & understand  the source? can we 
modify, rebuild, and redeploy at will? can we distribute modifications? The 
only gray area here is of technical nature, like there may be firmware 
literally without source, as in well-documented byte-code.

I like how you draw the distinction between options 1 & 2, but I hope you 
yourself can see, this is not a soft, but a hard distinction: there's a 
certain feeling that option 1 *hardware* won't be so likely to serve you a 
turd. So the topic you are digging is free hardware, which is a very murky and 
difficult topic at the moment. And again, FSF is right where it needs to be 
with a great compromise, which involves well-documented, audited hardware, as 
far as I can tell (please correct me if I misrepresent the hardware 
certification process).

However, there's no deep difference between (1) and (2). The issue at hand is 
that (1) as well as (2) is a blob of silicon, impractical to inspect, modify, 
or share with others, and the "source" for it is impossible to pin down, as 
it's the entire manufacturing process. So I believe we just need to keep our 
hardware as clean as we possibly can using the social and legal means, while 
paving the way for 3d-printing it in the future. If we can get to the point 
where a neighborhood print shop can (legally) bake libre chips, the free 
hardware problem will be solved once and for all.

On Friday, February 03, 2017 15:37:32 David Craven wrote:
> 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.

signature.asc
Description: This is a digitally signed message part.