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

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

[David Craven]

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.

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

[Taylan Ulrich Bayırlı/Kammer]

David Craven <david@craven.ch> writes:

> 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.

Being freely redistributeable doesn't make a blob free software
obviously, so endorsing such blobs would be out of the question as per
the core principles of the FSF.  Correct me if I misunderstand.

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

Sounds good.  Having non-free software hidden within a hardware device
is obviously no better than having the OS insert it there whenever the
device is connected, as per the reasons you explained.  (Assuming I
understood it correctly that that's how it normally works; I'm a
hardware noob.  I actually thought firmware blobs are just code loaded
into kernel space, like drivers.  Embarrassing?)

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

Definitely yes.

If I understand the situation correctly, I definitely agree that the FSF
should stop being blind to proprietary software hidden within hardware
devices in their endorsements.  Such devices should be discouraged.  But
the FSF would never endorse any other proprietary software / binary
blobs either, if I know anything about their principles. :-)  (And I
agree with those principles, to be clear.)

Thanks for raising this issue.  I had not heard of the trend of putting
proprietary firmware directly into flash storage on hardware devices to
give the illusion that they don't require binary blobs to run.

Taylan

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

[David Craven]

Hi Taylan,

> Being freely redistributeable doesn't make a blob free software
> obviously, so endorsing such blobs would be out of the question as per
> the core principles of the FSF.  Correct me if I misunderstand.

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.

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

[Christopher Howard]

Hi David, I don't agree that just being given a redistributable blob is
any wonderful thing. What you end up with down the road (and this is
where we are now) is systems that need several (or many) blobs that only
the providing company understands and controls. Usually these blobs are
in control of critical or highly desirable functionality. You don't know
for sure what the blobs do or whether or not they have security
vulnerabilities. And sometimes the blobs come with restrict licensing
allowing distribution but not allowing you to reverse engineer.

For firmware development to be practical, you want more than
documentation. You want source code. Also (for embedded development) you
want a tool chain. You might have the source code but find it near
impossible to build because you don't have a good tool chain.

Yeah, with documentation, you might be able to engineer the source code
and tool chain... but it might take you 3+ years, and then only if
enough people are interested. And by that time no one will want the
hardware anymore. This isn't a moderately annoying problem for x86, but
it is a major problem for tablets, cell phones, and other embedded
development.

The companies that should be the rewarded are the ones that release
firmware, source code, and tool chain. E.g., Thinkpenguin and the TPE-R1100.

On 02/03/2017 09:18 AM, David Craven wrote:
> Hi Taylan,
> 
>> Being freely redistributeable doesn't make a blob free software
>> obviously, so endorsing such blobs would be out of the question as per
>> the core principles of the FSF.  Correct me if I misunderstand.
> 
> 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.
> 

-- 
Christopher Howard, Computer Assistant
Alaska Satellite Internet
3239 La Ree Way, Fairbanks, AK 99709
907-451-0088 or 888-396-5623 (toll free)
fax: 888-260-3584
mailto:christopher@alaskasi.com
http://www.alaskasatelliteinternet.com

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

[David Craven]

Hi Christopher,

I like to understand things. For me the most important thing is that I
have the documentation available to me and can study how it works. For
most modern chips there is simply no documentation available to me.
But I guess you are right, even if I think that some hardware that
works with linux-libre is less favorable than some that does not.

Thank you for your reply.

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

[Maxim Cournoyer]

[-- Attachment #1: Type: text/plain, Size: 4182 bytes --]

Hi,

Christopher Howard <christopher@alaskasi.com> writes:

> Hi David, I don't agree that just being given a redistributable blob is
> any wonderful thing. What you end up with down the road (and this is
> where we are now) is systems that need several (or many) blobs that only
> the providing company understands and controls. Usually these blobs are
> in control of critical or highly desirable functionality. You don't know
> for sure what the blobs do or whether or not they have security
> vulnerabilities. And sometimes the blobs come with restrict licensing
> allowing distribution but not allowing you to reverse engineer.
>

+1. I don't see how having blobs helps security at all. David, you
mentioned that having blobs could help manufacturers fix security issues
(human errors) in their products; while true, this is a double-edged
sword; it could also be used to insert spyware or whatnot, and very
easily (simply release a new version of the blob for distribution,
advertising it as bringing "fixes").

I think the FSF's position, as expressed in their "Respects Your
Freedom" certification guidelines [0], is reasonable given the current
state of things. Basically it says that "All the product software must
be free software.", but grants some exceptions for software equivalent
to hardware (e.g., fixed in ROM and non-upgradable) [1] and which runs
on "secondary embedded processors" (which can include firmware built
into I/O devices).

For the time being, the hardware we use is closed. Just as we
reluctantly accept to use non-free hardware for the time being, we can
reluctantly accept to use non-free software which is equivalent to
hardware. Whether the non-free firmware is stored as a loadable blob or
in the ROM of a device doesn't change the fact that it's non-free. The
subtlety is whether this firmware is used as hardware (upgradable) or
software (easily replaced or extended). The later puts more control in
the hands of the manufacturer, which is why the former is preferred.

The RYF criteria page also states that they "want users to be able to
upgrade and control the software on as many levels as possible.". In
other words, a device with completely free firmware is more valued than a
device with a closed firmware used as hardware, as it should be.

Finally, preferring built-in, closed firmware to loadable blobs (closed
firmware) could be seen as an incentive for manufacturers to release
their firmware as free software (user-upgradable): releasing it as free
software enables them to fix things (in a transparent manner) after the
product is launched, which reduces risk (if the firmware is
non-upgradable, the product could have to be recalled in case a serious
problem is later found with it).

> For firmware development to be practical, you want more than
> documentation. You want source code. Also (for embedded development) you
> want a tool chain. You might have the source code but find it near
> impossible to build because you don't have a good tool chain.
>

The RYF criteria includes a "Compilation" (all the software must be
buildable using free tools) and "Documentation", so this is at least
summarily covered.

> Yeah, with documentation, you might be able to engineer the source code
> and tool chain... but it might take you 3+ years, and then only if
> enough people are interested. And by that time no one will want the
> hardware anymore. This isn't a moderately annoying problem for x86, but
> it is a major problem for tablets, cell phones, and other embedded
> development.
>
> The companies that should be the rewarded are the ones that release
> firmware, source code, and tool chain. E.g., Thinkpenguin and the TPE-R1100.
>

Indeed, we ought to put our money where our mouth is, i.e. back the
companies which are helping the cause of free software/hardware.

My two cents,

Maxim


[0] http://www.fsf.org/resources/hw/endorsement/criteria

[1] The "fixed" part is not worded directly in the RYF criteria, but
from the anti-tivoization clause found in the GPLv3, I would expect that
this is how they would consider the matter.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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

[David Craven]

Hi Maxim

> +1. I don't see how having blobs helps security at all.

Well the problem I was getting at is that things are not as fixed as
they may seem.
Quoting wikipedia:

>> Decreasing cost of reprogrammable devices had almost eliminated the market for mask ROM by the year 2000.

Translation: ROM is not RO.

It is not a theoretical threat, and just as dangerous as other threats
that people put a lot of effort in avoiding [0]

I don't see how trusting the manufacturer when buying the product is
any different from trusting him down the road. I was talking about
malicious third parties. Obviously planting something in difficult to
upgrade persistent memory is a lucrative target for attackers -
manipulating firmware becomes plain uninteresting in the other case.

> The companies that should be the rewarded are the ones that release
> firmware, source code, and tool chain. E.g., Thinkpenguin and the TPE-R1100.

> Indeed, we ought to put our money where our mouth is, i.e. back the
> companies which are helping the cause of free software/hardware.

I don't think they actually produce any silicon, toolchain or firmware
themselves. At least I didn't find a link to it. So they are basically
using other peoples silicon, toolchain and firmware. Giving them
credit for complying with the GPL is not quite right either. (But I
don't know who's behind the thinkpenguin and it looks like a great
accomplishement).

To independently verify the claim that the firmware they are using is
indeed fixed, would actually require them to release both schematics
and datasheets of their designs.

[0] https://www.wired.com/2015/02/nsa-firmware-hacking/

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

[Christopher Howard]

On 02/10/2017 08:31 AM, David Craven wrote:
> Hi Maxim
> 
>> +1. I don't see how having blobs helps security at all.
> 
> Well the problem I was getting at is that things are not as fixed as
> they may seem.
> Quoting wikipedia:
> 
>>> Decreasing cost of reprogrammable devices had almost eliminated the market for mask ROM by the year 2000.
> 
> Translation: ROM is not RO.
> 
> It is not a theoretical threat, and just as dangerous as other threats
> that people put a lot of effort in avoiding [0]
> 
> I don't see how trusting the manufacturer when buying the product is
> any different from trusting him down the road. I was talking about
> malicious third parties. Obviously planting something in difficult to
> upgrade persistent memory is a lucrative target for attackers -
> manipulating firmware becomes plain uninteresting in the other case.
> 
>> The companies that should be the rewarded are the ones that release
>> firmware, source code, and tool chain. E.g., Thinkpenguin and the TPE-R1100.
> 
>> Indeed, we ought to put our money where our mouth is, i.e. back the
>> companies which are helping the cause of free software/hardware.
> 
> I don't think they actually produce any silicon, toolchain or firmware
> themselves. At least I didn't find a link to it. So they are basically
> using other peoples silicon, toolchain and firmware. Giving them
> credit for complying with the GPL is not quite right either. (But I
> don't know who's behind the thinkpenguin and it looks like a great
> accomplishement).
> 
> To independently verify the claim that the firmware they are using is
> indeed fixed, would actually require them to release both schematics
> and datasheets of their designs.
> 
> [0] https://www.wired.com/2015/02/nsa-firmware-hacking/
> 

Stallman did an extensive article in 2015 which I think is relevant to
this discussion:

https://www.gnu.org/philosophy/free-hardware-designs.en.html

I don't have the schematics for TPE-R1100, though I think they would
send them if I asked. It is based on the AR9331 SoC which is quite open.
There was one other large chip on the board... I'll have to check what
that is after I get home.

-- 
Christopher Howard, Computer Assistant
Alaska Satellite Internet
3239 La Ree Way, Fairbanks, AK 99709
907-451-0088 or 888-396-5623 (toll free)
fax: 888-260-3584
mailto:christopher@alaskasi.com
http://www.alaskasatelliteinternet.com

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

[Maxim Cournoyer]

[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]

Hi,

Christopher Howard <christopher@alaskasi.com> writes:

> On 02/10/2017 08:31 AM, David Craven wrote:
>> Hi Maxim
>> 
>>> +1. I don't see how having blobs helps security at all.
>> 
>> Well the problem I was getting at is that things are not as fixed as
>> they may seem.
>> Quoting wikipedia:
>> 
>>>> Decreasing cost of reprogrammable devices had almost eliminated the market for mask ROM by the year 2000.
>> 
>> Translation: ROM is not RO.
>>

You have a point, although reading the article linked (from Wired), this
kind of attack requires a lot of effort (to reverse engineer the
proprietary interfaces used to reprogram the firmware of a HD). At this
level of seriousness they might as well find other means to get at
you, such as physically altering one of the device you use without you
noticing.

>> It is not a theoretical threat, and just as dangerous as other threats
>> that people put a lot of effort in avoiding [0]
>>

They were using Windows and allowing people to shuffle USB keys. That
fits strangely with "putting a lot of effort in avoiding security risks"
;).

>> I don't see how trusting the manufacturer when buying the product is
>> any different from trusting him down the road. I was talking about
>> malicious third parties. Obviously planting something in difficult to
>> upgrade persistent memory is a lucrative target for attackers -
>> manipulating firmware becomes plain uninteresting in the other case.
>> 
>>> The companies that should be the rewarded are the ones that release
>>> firmware, source code, and tool chain. E.g., Thinkpenguin and the TPE-R1100.
>> 
>>> Indeed, we ought to put our money where our mouth is, i.e. back the
>>> companies which are helping the cause of free software/hardware.
>> 
>> I don't think they actually produce any silicon, toolchain or firmware
>> themselves. At least I didn't find a link to it. So they are basically
>> using other peoples silicon, toolchain and firmware. Giving them
>> credit for complying with the GPL is not quite right either. (But I
>> don't know who's behind the thinkpenguin and it looks like a great
>> accomplishement).
>>

Probably not themselves, but they could hire someone to work on it. I
remember reading a story where ThinkPenguin had been involved in
negotiating with a hardware company and played a part in having that
company agree to release their firmware. Sadly I can't find that story
anymore!  And the company seems active in the free software community
and promoting/defending values of the movement. You can have a look at
their blog to see for yourself (https://www.thinkpenguin.com/blog).

>> To independently verify the claim that the firmware they are using is
>> indeed fixed, would actually require them to release both schematics
>> and datasheets of their designs.
>> 
>> [0] https://www.wired.com/2015/02/nsa-firmware-hacking/
>> 
>
> Stallman did an extensive article in 2015 which I think is relevant to
> this discussion:
>
> https://www.gnu.org/philosophy/free-hardware-designs.en.html
>

A recommended read for anyone interested in the idea of free hardware!
Thanks for sharing.

Maxim

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

On Sun, Feb 12, 2017 at 11:02:29PM -0800, Maxim Cournoyer wrote:
     Hi,
     
     Christopher Howard <christopher@alaskasi.com> writes:
     
     > On 02/10/2017 08:31 AM, David Craven wrote:
     >> Hi Maxim
     >> 
     >>> +1. I don't see how having blobs helps security at all.
     >> 
     >> Well the problem I was getting at is that things are not as fixed as
     >> they may seem.
     >> Quoting wikipedia:
     >> 
     >>>> Decreasing cost of reprogrammable devices had almost eliminated the market for mask ROM by the year 2000.
     >> 
     >> Translation: ROM is not RO.
     >>
     
     You have a point, although reading the article linked (from Wired), this
     kind of attack requires a lot of effort (to reverse engineer the
     proprietary interfaces used to reprogram the firmware of a HD). At this
     level of seriousness they might as well find other means to get at
     you, such as physically altering one of the device you use without you
     noticing.

If the attacker *is* vendor who supplies the proprietary device then they would
not have to reverse engineer it.
     



-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[David Craven]

> If the attacker *is* vendor who supplies the proprietary device then they would
> not have to reverse engineer it.

You can always choose not to apply the vendors update. If for example
the company you initially trusted with by purchasing their device gets
bought by another company or you have some other reason to stop
trusting it. CEO changed, their website was hacked or whatever.

> A recommended read for anyone interested in the idea of free hardware!
> Thanks for sharing.

Don't know if you've heard of sifive [0]. If there is a startup that
has the potential to create lasting change in the semiconductor
industry, my money is on them... :) I should be getting one of the
first riscv boards soon!

[0] https://www.sifive.com/

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

[Hartmut Goebel]

Am 13.02.2017 um 20:24 schrieb David Craven:
> You can always choose not to apply the vendors update.

Is the vendor always trustworthy?

Think about vulnerabilities in e.g. router firmware from companies like
Cisco and Juniper, which were undiscovered for a long time – and one can
reasonably argue that these have been back-doors. Also Intel Chips
include a lot of magic called "Intel Management Engine" (IME) or "Active
Management Technology" [1].

[1] https://en.wikipedia.org/wiki/Intel_Active_Management_Technology

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

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

[David Craven]

> Is the vendor always trustworthy?

I agree with you. But the thing is that we already bought the device.
It says on the label that the device does A and only A at time x when
we bought the device. The question is do we need to add more trust
than that to the equation.

If we look at security as a function we are trying to maximize, we
already introduced one axiom, that device does A and only A at time x.
By putting the firmware in ROM instead of fixing it with a hash we are
introducing a new axiom. That our previous axiom is time invariant.

Also consider this:
Device comes with firmware A 2015. The vendor creates an update B. In
2016 the same device comes with firmware B. You were happy with the
device in 2015 but your laptop was stolen or broke. So you buy the
same device in 2016. That is a hidden firmware update. How is that
different than knowing that you updated your firmware? In this case
you simply pretend that you have not updated your device, but the
truth is - you really don't know.

So the more axioms (assumptions) our security is based on - the weaker
is the house of cards we are building.

But I'm totally fine with burring this discussion.

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

[Maxim Cournoyer]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

David Craven <david@craven.ch> writes:

>> If the attacker *is* vendor who supplies the proprietary device then they would
>> not have to reverse engineer it.
>
> You can always choose not to apply the vendors update. If for example
> the company you initially trusted with by purchasing their device gets
> bought by another company or you have some other reason to stop
> trusting it. CEO changed, their website was hacked or whatever.
>

Either ways, as long as it's opaque, either shipped in a (semi) fixed
state or loaded at runtime, it's not auditable, so there's nothing too
interesting to be discussed in regards of trust or freedom. The later at
least doesn't clutter our view (and the Linux git tree) -- blobs have
grown from ~10 MiB in Linux 2.6.33 [0] to 158 MiB (du -sh on a checkout of
the the linux-firmware git tree [1] (pruned from its .git))

>> A recommended read for anyone interested in the idea of free hardware!
>> Thanks for sharing.
>
> Don't know if you've heard of sifive [0]. If there is a startup that
> has the potential to create lasting change in the semiconductor
> industry, my money is on them... :) I should be getting one of the
> first riscv boards soon!
>
> [0] https://www.sifive.com/

I had followed some earlier developments but had lost track recently!
I'm happy to see that they have released the sources of their
microcontroller chip design. Apparently the design (Apache licensed) is
described using a tool/language called Chisel, which is Scala based and
can generate two flavors of Verilog as well as a C++ version for
simulation purposes. Interesting times!

Maxim

[0] https://www.fsfla.org/ikiwiki/anuncio/2010-03-Linux-2.6.33-libre.en
[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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

[David Craven]

> I had followed some earlier developments but had lost track recently!
> I'm happy to see that they have released the sources of their
> microcontroller chip design.

It's more than a microcontroller chip design. The people behind sifive are
from uc berkeley and also developed a full gcc toolchain backend, a linux
port, a qemu and a clang port.

They have taped out multiple chips capable of booting Linux, and are
still working on putting the finishing touches on the privileged architecture
spec which is an open collaborative effort of the RISCV foundation, before
releasing their SoC.. The sifive developers play an important role there.

Benchmarks for code size and performance show that their SoC and the
ISA they developed is comparable to and out performs at least all ARM
cortex-a chips with an in-order-pipeline.

They also are developing and have taped out an out-of-order core. All of
their developments are released as free hardware.

Their specifications have enabled me to study a real world instruction set
architecture, studying something like ARM or x86 - I'm sure people have
looked at those manuals - are not something a beginner can study to
any form of completeness, they are simply to large and too complicated.

Cheers,
David

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

[Denis 'GNUtoo' Carikli]

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.

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

[Maxim Cournoyer]

[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]

Hi David,

David Craven <david@craven.ch> writes:

>> I had followed some earlier developments but had lost track recently!
>> I'm happy to see that they have released the sources of their
>> microcontroller chip design.
>
> It's more than a microcontroller chip design. The people behind sifive are
> from uc berkeley and also developed a full gcc toolchain backend, a linux
> port, a qemu and a clang port.
>
> They have taped out multiple chips capable of booting Linux, and are
> still working on putting the finishing touches on the privileged architecture
> spec which is an open collaborative effort of the RISCV foundation, before
> releasing their SoC.. The sifive developers play an important role there.
>
> Benchmarks for code size and performance show that their SoC and the
> ISA they developed is comparable to and out performs at least all ARM
> cortex-a chips with an in-order-pipeline.
>
> They also are developing and have taped out an out-of-order core. All of
> their developments are released as free hardware.
>
> Their specifications have enabled me to study a real world instruction set
> architecture, studying something like ARM or x86 - I'm sure people have
> looked at those manuals - are not something a beginner can study to
> any form of completeness, they are simply to large and too complicated.
>

Impressive! Sounds like something I should look more into :) Thanks for
sharing.

Maxim

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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

[David Craven]

Hi Denis,

Thank you for your extensive feedback.

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

I considered using this option but realized that I had a buggy thunderbolt
controller in my laptop, that I can only update from a windows computer
and therefore know for sure it can be modified remotely poses a much
larger security issue, that I would not actually gain anything from replacing
my wifi card. And besides these obvious and visible firmwares I have no
clue what other non-free firmware is running on my laptop.

I concluded that if I didn't know, that likely most linux-libre users didn't
know either and where likely much less aware of what that could actually
mean.

While obviously you understand hardware and the hardware you are
using, most people do not. And I think we need to make sure that
people that don't - I consider myself being one of those people - can do
the *best* with what we have and have the information available to us
to make informed decisions.

I bought my dell xps developer edition before I had any involvement
with a GNU project, and I bought it because dell was actually providing
at least some kind of linux support. I currently can't afford to buy a new
laptop even if the one you are using is much more free. Besides I have
the dream of building a replacement mainboard with a RISCV SoC for
it. But that is still beyond my capabilities :) FYI: This dream mainboard
would also feature a software defined radio [0] instead of a wifi card -
another interesting free hardware project, although the sources have
not been released yet.


Another thing I found very frustrating was a conversation that I had
on IRC. It went like this:

Can guixsd run on a RPiv2?

Yes, sure. You'll need to use vanilla linux and add some firmware, I'll
show you how to do it.

No thank you. I don't want to use binary blobs. I'll just use another
distro until guixsd works without binary blobs.

I expect that everyone recognizes the irony in that.

> While this is really great and that each new free firmware is a great
> achievement

I agree.

> 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...

Yes with buggy thunderbolt controllers this is becoming a real problem.

> 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.

Replicant looks very interesting, especially since I owned quite a few of
those nexus devices that are supported. Sadly not anymore :/

I wasn't aware that there was so much documentation available about
mobile devices. How do you know all that stuff? :)

Thank you for your input,
David

[0] https://xtrx.io/

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

[Adonay Felipe Nogueira]

About that conversation involving some GuixSD user: He gave that kind of
recommendation so easily? I'm shocked...

Unless the conversation was cut somewhere, I didn't see indication that
you wanted/want to develop free/libre replacement for the non-free
software needed for RPI 2 to work. In this case, that is if he was
wasn't made aware of such commitment (if it ever exists on your part),
then he shouldn't have made such recommendation, according to
[[http://www.gnu.org/philosophy/applying-free-sw-criteria.html]] and [[http://www.gnu.org/philosophy/is-ever-good-use-nonfree-program.html]].

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

[David Craven]

> About that conversation involving some GuixSD user: He gave that kind of
> recommendation so easily? I'm shocked...

The irony is that unless you know as much about hardware as Denis you
ARE USING NON-FREE FIRMWARE. As proven by you suggestion to simply use
a different distro.

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

[Christopher Howard]

Some folks are working a free firmware for Rpi2:

https://wiki.debian.org/RaspberryPi2

What you say below is not necessarily true. You can buy libre systems.
Of course, sometimes they cost more... but in a non-ideal world freedom
sometimes comes with a price. Anyway, the point of projects like this
and RYF and other libre projects is to make freedom available to
everyone, even the "non-technical" folks.

David, I think you need to give up wasting your time trying to convince
a Gnu/Linux *Libre* list that proprietary kernel blobs are a good idea.
Most people are here because they care more about freedom than getting
the support of every manufacturer on the market. If you want to make
headway, just register at any "Linux" forum on the web and you'll find
that 80% of the people there already agree with you.

On 02/14/2017 11:47 AM, David Craven wrote:
>> About that conversation involving some GuixSD user: He gave that kind of
>> recommendation so easily? I'm shocked...
> 
> The irony is that unless you know as much about hardware as Denis you
> ARE USING NON-FREE FIRMWARE. As proven by you suggestion to simply use
> a different distro.
> 

-- 
Christopher Howard, Computer Assistant
Alaska Satellite Internet
3239 La Ree Way, Fairbanks, AK 99709
907-451-0088 or 888-396-5623 (toll free)
fax: 888-260-3584
mailto:christopher@alaskasi.com
http://www.alaskasatelliteinternet.com

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

[David Craven]

> David, I think you need to give up wasting your time trying to convince
> a Gnu/Linux *Libre* list that proprietary kernel blobs are a good idea.
> Most people are here because they care more about freedom than getting
> the support of every manufacturer on the market. If you want to make
> headway, just register at any "Linux" forum on the web and you'll find
> that 80% of the people there already agree with you.

I really love guixsd and want people to use it. That's the only reason I'm
trying to convince anyone of anything.

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

[David Craven]

And to be clear I never suggested adding the raspberry pi firmware to
a FSDG compliant distribution.

I don't think the suggestion I made actually qualifies the raspberry
pi firmware - or any current firmware for that matter. It was made to
encourage hardware manufacturers that are willing to dip a toe in to
becoming more open, without getting scorned for not going all the way.

Anyway I'm sorry that this discussion has gotten out of hand.

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

[Denis 'GNUtoo' Carikli]

On Tue, 14 Feb 2017 19:43:48 +0100
David Craven <david@craven.ch> wrote:

> Hi Denis,
Hi,

> 
> > With that we can still use WiFi by ignoring the intel wifi card and
> > using an USB wifi card instead.  
> 
> [Thunderbolt] poses a much larger security issue,
> that I would not actually gain anything from replacing my wifi card.
> And besides these obvious and visible firmwares I have no clue what
> other non-free firmware is running on my laptop.
While security is important, it's far from being the only reason that
makes free software important.
When security and freedom conflicts, I usually prefer freedom.

That said, if you care about free software only for the security and
privacy benefits:
- With Respect Your Freedom(RYF) certified computer, firmware freedom
  matters a lot.
- Not considering non-free firmware as an issue and having most FSDG
  distribution users run them would make freeing firmwares appear way
  less important.
  Most GNU/Linux users aren't even aware of hardware related freedom
  issues, because it just works. According to many of them the ATI GPU
  can be used with fully free software, and some even think that
  everything in their distribution is free software.
  This doesn't help promoting the importance of having free firmwares,
  and way less developers would want to work on their replacement.
  More broadly, users that need the hardware to work would not care
  anymore about free firmwares anymore either.
  To successfully convince Atheros to liberate the firmware of the
  ath9k_htc compatible chips, thinkpenguin probalby needed a valid
  buisness case, which probably was selling USB WiFi dongles to users
  that desperately wanted WiFi to work with free software.

> While obviously you understand hardware and the hardware you are
> using, most people do not. And I think we need to make sure that
> people that don't - I consider myself being one of those people - can
> do the *best* with what we have and have the information available to
> us to make informed decisions.
I think that not using non-free firmwares is the best decision for all
users collectively. If more users and developers were taking that
decisions, we would not have the issue we have here:
- You have hardware that doesn't work because it requires non-free
  firmwares.
- Many non-free firmwares aren't being replaced because there is not
  enough interest in replacing them, because many GNU/Linux
  distributions still ship non-free firmwares and it works for their
  developers and/or users.

The more interest in free software replacement, the more probability
there is to have them replaced with free software.

> I bought my dell xps developer edition before I had any involvement
> with a GNU project, and I bought it because dell was actually
> providing at least some kind of linux support. I currently can't
> afford to buy a new laptop even if the one you are using is much more
> free.
You may be able to find cheap or gratis laptops supported by the
libreboot project but it will require you to spend time for that, with
no guarantee of success.
As for how cheap it can get, I bought a Lenovo
Thinkpad X60 for about 50E. The downside is that, at that time, I was
lucky to find it that cheap, and that its CPU is single core. Since I
bought it to use it for coreboot/libreboot development/testing only, I
didn't need a fast CPU.

> Besides I have the dream of building a replacement mainboard
> with a RISCV SoC for it. But that is still beyond my capabilities :)
> FYI: This dream mainboard would also feature a software defined radio
> [0] instead of a wifi card - another interesting free hardware
> project, although the sources have not been released yet.
RISCV is probably not yet ready to be used as a laptop SOC. However
there are some microcontrollers projects with that architecture:
- https://www.crowdsupply.com/onchip/open-v
- https://www.crowdsupply.com/sifive/hifive1

As a side note, if you think that microcontrollers are not very
useful, think again because, since you have some interest in security
and probably privacy as well:
- Microcontrollers can have critical security functions, as it is the
  case in this computer: https://www.crowdsupply.com/design-shift/orwl
  They can also be used for password external management.
- We probably have the Hardware description language source for it
  under a free software license.

> Another thing I found very frustrating was a conversation that I had
> on IRC. It went like this:
> 
> Can guixsd run on a RPiv2?
> 
> Yes, sure. You'll need to use vanilla linux and add some firmware,
> I'll show you how to do it.
> 
> No thank you. I don't want to use binary blobs. I'll just use another
> distro until guixsd works without binary blobs.
> 
> I expect that everyone recognizes the irony in that.
I don't. I don't see any issue with the above assuming that non-free
firmwares are the only difference between the "other distro" and the
free software distribution.

Missleading users into thinking that they run 100% free software
everywhere is not a good idea:
- As a user, If I run Trisquel or Parabola, I assume that everything
  that this distribution ships is free software.
- As a user, I don't want to have to review each package for
  proprietary software, this is the role of the distribution.
- As a user knowing how hardware works, I however know that Trisquel or
  Parabola are not the only software running on my computer:
  - Coreboot/Libreboot runs without any blobs
  - The proprietary Embedded controller firmware runs.
  - The HDD firmware runs.
  - Some other firmware that I'm not aware of might run on some chips.
    It also depends on which laptop and peripherals I use:
    - If I use an X60 Tablet, it might have some touchscreen controller
firmware.
    - If I use an external mouse, it might have a firmware too.

> > While this is really great and that each new free firmware is a
> > great achievement  
> 
> I agree.
It would be sad not to continue freeing firmwares. Especially if more
and more functionality and trust is being put in them.

> > 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...  
> 
> Yes with buggy thunderbolt controllers this is becoming a real
> problem.
Yes it is, however there are mitigations in some cases:
- It might be possible to have them disabled, there might also be some
  other workarounds.
- Thunderbolt tend to be present on recent hardware, and some of that
  recent hardware also have an IOMMU that can protect the RAM from DMA
  attacks. Note that not all recent computers supports it, see
  https://www.qubes-os.org/hcl/ for more details.
- If you take firewire, and the firewire_ohci module, you have the
  following module parameter:
  > remote_dma:Enable unfiltered remote DMA (default = N) (bool)
  I didn't research yet how it works to understand what it exactly
  means, but some hardware, in some conditions, can mitigate such
  issues.

> I wasn't aware that there was so much documentation available about
> mobile devices. How do you know all that stuff? :)
- I learned most/all that knowledge by working on Replicant and
  researching myself the various freedom privacy and security issues.
- You can however take a huge shortcut and instead read the following:
  http://www.replicant.us/freedom-privacy-security-issues.php

I think that documentation is really important and in many cases as
much important as the sofware itself.

> [0] https://xtrx.io/
You forgott to add a [0] in the mail text that points to this reference.

Denis.

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

[David Craven]

> While security is important, it's far from being the only reason that
> makes free software important.
> When security and freedom conflicts, I usually prefer freedom.

I agree here too. While security and privacy are a factor for me
it's far from the most important. To me the most important is
it's role in increasing computer literacy and education and how it
helps small businesses to be competitive which leads to a
distribution of wealth.

I think it helps to remember that free software is a
means to an end and focus more on the end.

It is my impression that too much focus is being placed on the
means. For example: All those services as software substitutes
are extremely important for computer illiterates, for small
businesses and for individuals that don't want to host their own
mail servers etc. As an example, I doubt that it would be really
that much more secure to host my own mailserver.

While Snowden did make us aware that many large "cloud"
service providers have had security breaches, I have not found
any evidence of malice on part of many of those providers. The
NSA was planting surveillance devices within and around their
data centers.

> I think that not using non-free firmwares is the best decision for all
> users collectively. If more users and developers were taking that
> decisions, we would not have the issue we have here:

I understand the sentiment, but I don't think that this is an effective
solution. Only because the firmware is in ROMs or a developer spent
the time to reverse engineer a firmware for a device does not reward
the right behavior and could actually lead to less free devices.

> I don't. I don't see any issue with the above assuming that non-free
> firmwares are the only difference between the "other distro" and the
> free software distribution.

I understand that that is the case for most FSDG distros, but guix has
merit in it's own right. If we focus on the end instead of the means,
guix can do a lot to increase computer literacy.

> Missleading users into thinking that they run 100% free software
> everywhere is not a good idea:

I had the impression that a computer running linux-libre was more
free than one that does not. When I realized that that was likely
not actually the case and that it depended on an array of other
factors I felt betrayed for having been led to believe that.

> It would be sad not to continue freeing firmwares. Especially if more
> and more functionality and trust is being put in them.

I think that the best way to free firmwares is by creating truly free
devices and firmwares. This sets an example and shows existing
companies that it is actually possible to sustain a business while
being open and creates the market pressure for them to release
their firmwares.

Again focusing on the end instead of the means, working on SDRs
and their firmware is much more important than reversing an intel
wifi firmware. The first can have a tremendous impact on computer
literacy and for small businesses and may one day lead to truly free
wifi cards, while the other "just" allows running linux-libre with intel
wifi cards.

I hope to not offend anyone - these are just my opinions and feelings :)

David