[Top][All Lists]

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

Re: [GNU-linux-libre] Free firmware - A redefinition of the term and a n

From: Isaac David
Subject: Re: [GNU-linux-libre] Free firmware - A redefinition of the term and a new metric for it's measurement.
Date: Fri, 03 Feb 2017 13:57:03 -0600

interesting discussion. I apologise in advance for replying to many
mails at once.

David Craven <address@hidden>:
We want to be able to exercise our freedoms in all parts of our
computing systems.

correct, all of them.

David Craven <address@hidden>:
Taylan Ulrich Bayırlı/Kammer <address@hidden>:
David Craven <address@hidden>:

 [...] focus on the following:

 1. The firmware is freely redistributeable

Being freely redistributeable doesn't make a blob free software

The requirements I proposed for the definition of free firmware is
already more than most companies are willing to do. Any company
willing to do these things should IMO get a medal pinned on their
chest and not be disadvantaged.

they should be encouraged to go further!

this is in contradiction with your opening remark. the freedom to copy
and share is necessary --and better than no freedom at all--, but it
isn't sufficient. the four freedoms are the inexorable standard. they
correctly characterise which software has a shot at acceptability and
which doesn't, and there are reasons we can discuss as to why this is
the case.

David Craven <address@hidden>:
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.

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

it shouldn't. the current situation is to be interpreted as saying:
"in case 2 firmware is non-free but the OS remains ethical, whereas in
case 1 both OS and firmware are wronging."

this of course assumes that no. 2 isn't actual ROM. otherwise, the
question of using that device boils down to trusting what an immutable
piece of hardware is doing.

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.

I would argue both are cases of security through obscurity when the
firmware is a binary-only blob. what good is a checksum when we don't
know the contents? it provides no protection against the biggest
threat: the vendor. by the same token, what good is bad source code
that we cannot fix and distribute thereafter?

With the second model there is no simple way to fix
vulnerabilities even if the vendor is aware and willing to fix it.

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

I agree that loading firmware from within the OS comes very handy for
a majority of users and distributors, but that doesn't mean external
re-flashing is untenable. I would rather have free firmware and a
clumsy external programmer board than proprietary firmware handled by
the kernel.

a final unimportant note: EEPROMS that are flashable solely from the
OS are a thing. Aren't they, hardware gurus?

Isaac David
GPG: 38D33EF29A7691134357648733466E12EC7BA943
Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C

reply via email to

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