Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #116270 > unrolled thread

Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion

Back to article view | Back to linux.debian.devel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion Simon Josefsson <simon@josefsson.org> - 2025-03-07 22:00 +0100
    Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion Bill Allombert <ballombe@debian.org> - 2025-03-08 12:50 +0100
      Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion Simon Josefsson <simon@josefsson.org> - 2025-03-08 13:50 +0100
        Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion Aurélien COUDERC <libre@coucouf.fr> - 2025-03-08 14:30 +0100
        Re: Reconsidering Debian’s Inclusion  of Non-Free Firmware - A Call for Discussion Andrey Rakhmatullin <wrar@debian.org> - 2025-03-08 15:00 +0100
          Re: Reconsidering Debian’s Inclusion  of Non-Free Firmware - A Call for Discussion Andrey Rakhmatullin <wrar@debian.org> - 2025-03-10 12:00 +0100
        Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion Simon Josefsson <simon@josefsson.org> - 2025-03-08 16:30 +0100
        Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-03-08 16:30 +0100
          Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion <tomas@tuxteam.de> - 2025-03-08 16:50 +0100
          Re: Reconsidering Debian’s Inclusion of  Non-Free Firmware - A Call for Discussion Stephan Verbücheln <verbuecheln@posteo.de> - 2025-03-08 23:40 +0100
    Re: Reconsidering Debian’s Inclusion of  Non-Free Firmware - A Call for Discussion Stephan Verbücheln <verbuecheln@posteo.de> - 2025-03-08 16:40 +0100

#116270 — Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion

[Multipart message — attachments visible in raw view] — view raw

pandya@disroot.org writes:

> I urge Debian to rethink its decision to officially include non-free
> firmware and correct the social contract. Instead of making non-free
> firmware the default, Debian should ensure that users consciously
> choose to install it while being made aware of the implications.

I agree and would personally come back to use Debian on some of my
laptops if there was a supported way to install Debian from official
installer images that did not promote non-free software by including
firmware on them.

The recent AMD Microcode vulnerability is a good case-study on the
dangers of permitting non-free code to run on your CPU:

https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking

There is no way for me as a user to audit that the Debian installer
images is not including vulnerable microcode, since source code for the
firmware is not available.

My perception is that the Debian developer community rejected this, and
I'm not sure people are ready to reconsider just yet (the trend seems to
be the opposite way).  Fortunately there are good libre alternatives in
Trisquel and Guix available for recommendation meanwhile.

/Simon

[toc] | [next] | [standalone]

#116285

Le Fri, Mar 07, 2025 at 07:33:53PM +0100, Simon Josefsson a écrit :
> pandya@disroot.org writes:
> 
> > I urge Debian to rethink its decision to officially include non-free
> > firmware and correct the social contract. Instead of making non-free
> > firmware the default, Debian should ensure that users consciously
> > choose to install it while being made aware of the implications.
> 
> I agree and would personally come back to use Debian on some of my
> laptops if there was a supported way to install Debian from official
> installer images that did not promote non-free software by including
> firmware on them.
> 
> The recent AMD Microcode vulnerability is a good case-study on the
> dangers of permitting non-free code to run on your CPU:
> 
> https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking

Do not fall for the marketing. What was broken was the DRM which
forbid you to fix the firmware on your own CPU. This is no more a
vulnerability than letting you boot your own OS.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here.

[toc] | [prev] | [next] | [standalone]

#116287

[Multipart message — attachments visible in raw view] — view raw

Bill Allombert <ballombe@debian.org> writes:

> Le Fri, Mar 07, 2025 at 07:33:53PM +0100, Simon Josefsson a écrit :
>> pandya@disroot.org writes:
>> 
>> > I urge Debian to rethink its decision to officially include non-free
>> > firmware and correct the social contract. Instead of making non-free
>> > firmware the default, Debian should ensure that users consciously
>> > choose to install it while being made aware of the implications.
>> 
>> I agree and would personally come back to use Debian on some of my
>> laptops if there was a supported way to install Debian from official
>> installer images that did not promote non-free software by including
>> firmware on them.
>> 
>> The recent AMD Microcode vulnerability is a good case-study on the
>> dangers of permitting non-free code to run on your CPU:
>> 
>> https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking
>
> Do not fall for the marketing. What was broken was the DRM which
> forbid you to fix the firmware on your own CPU. This is no more a
> vulnerability than letting you boot your own OS.

My point was that there is no reasonable way to gain confidence about
security properties of any piece of non-free microcode.  Everyone can
now produce AMD microcode that corrupts your machine in advanced ways
that evade detection, but we don't know if such malicious corruption is
included in the official microcode.  Having source code for the
microcode would help gain confidence in it, and is the reasonable
request.  If the request is denied, I would consider the vendor not
trustworthy and look into options.

This is a similar vulnerability as installing a non-free operating
system like Windows.  You essentially have to trust the vendor to
provide you with software, which you have no good way of auditing and
ultimately end up in their control.  It wouldn't be a big problem if
software were free of vulnerabilities and never needed updates, but just
like Windows has had bugs, microcode have bugs.

https://www.gnu.org/philosophy/free-software-even-more-important.html

/Simon

[toc] | [prev] | [next] | [standalone]

#116288

Le 8 mars 2025 13:43:26 GMT+01:00, Simon Josefsson <simon@josefsson.org> a écrit :

> Having source code for the
>microcode would help gain confidence in it, and is the reasonable
>request.  If the request is denied, I would consider the vendor not
>trustworthy and look into options.

How about you try asking the vendors for that instead of speculating ?

Unless you come back with very unexpected good news you definitely need to look for alternatives.

As for Debian as a project we've voted on the topic not so long ago and decided we want to ship available firmware with the default installer. I don't see which new bits of information would make us vote differently now.


Happy hacking,
--
Aurélien

[toc] | [prev] | [next] | [standalone]

#116289 — Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion

[Multipart message — attachments visible in raw view] — view raw

On Sat, Mar 08, 2025 at 02:51:29PM +0100, Johannes Schauer Marin Rodrigues wrote:
>If you don't trust the vendor, then it makes no difference whether or not new
>official firmware/microcode can be uploaded/flashed or not. If you don't trust
>the vendor, then the initial microcode that came with your device might already
>be doing things that go against your interests.
>
>Of course we cannot have much confidence in a piece of microcode of which we do
>not have the source code. But we also cannot have much confidence in a piece of
>hardware with non-flashable firmware of which we don't have the vhdl/verilog
>sources. So what is the difference?

This is an old argument that didn't work for people holding this opinion 
before and do I wouldn't expect it to work now. I don't expect that 
people's opinions on this matter can be changed.


-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#116367 — Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion

[Multipart message — attachments visible in raw view] — view raw

On Sat, Mar 08, 2025 at 06:58:08PM +0500, Andrey Rakhmatullin wrote:
>>If you don't trust the vendor, then it makes no difference whether or not new
>>official firmware/microcode can be uploaded/flashed or not. If you don't trust
>>the vendor, then the initial microcode that came with your device might already
>>be doing things that go against your interests.
>>
>>Of course we cannot have much confidence in a piece of microcode of which we do
>>not have the source code. But we also cannot have much confidence in a piece of
>>hardware with non-flashable firmware of which we don't have the vhdl/verilog
>>sources. So what is the difference?
>
>This is an old argument that didn't work for people holding this 
>opinion before and do I wouldn't expect it to work now. I don't expect 
>that people's opinions on this matter can be changed.


See?

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#116290

[Multipart message — attachments visible in raw view] — view raw

Johannes Schauer Marin Rodrigues <josch@debian.org> writes:

> Hi,
>
> Quoting Simon Josefsson (2025-03-08 13:43:26)
>> My point was that there is no reasonable way to gain confidence about
>> security properties of any piece of non-free microcode.  Everyone can now
>> produce AMD microcode that corrupts your machine in advanced ways that evade
>> detection, but we don't know if such malicious corruption is included in the
>> official microcode.  Having source code for the microcode would help gain
>> confidence in it, and is the reasonable request.  If the request is denied, I
>> would consider the vendor not trustworthy and look into options.
>
> I do not understand something about this argument.
>
> If you don't trust the vendor, then it makes no difference whether or not new
> official firmware/microcode can be uploaded/flashed or not. If you don't trust
> the vendor, then the initial microcode that came with your device might already
> be doing things that go against your interests.
>
> Of course we cannot have much confidence in a piece of microcode of which we do
> not have the source code. But we also cannot have much confidence in a piece of
> hardware with non-flashable firmware of which we don't have the vhdl/verilog
> sources. So what is the difference?

These are good questions and I believe that if you can see that there is
a difference between the two positions, it is easier to appreciate the
need for fully free operating systems, and that not offering fully free
Debian installer images (even as an option) is problematic.

Many years ago I also reacted the same way you and many others do --
"there is no difference between the act of loading non-free firmware
into my hardware and then using it compared to the act of using my
hardware that contains non-free software in it".

However I have come to realize that, yes, there is a significant and
fundamental difference between these two cases.

I'm not good at explaining this difference, and I believe the reason so
many still believe there is no differeence between these positions
suggests that we need better ways to articulate the difference.  I'm
sure most people here are familiar with RMS' argument on this:

https://www.gnu.org/distros/free-system-distribution-guidelines.html

The way that I came to understand and appreciate the difference between
the act of loading non-free firmware into hardware, and the act of using
non-free firmware in hardware, is to first acknowledge that hardware is
different from software.  Software people often think that their ideals
on how to design things should apply equally to hardware.  Hardware
people often think the reverse.  I've seen these patterns collide many
times, notably when I was involved with Yubico.  The escape mechanism is
to acknowledge that there has to be different ideals.  You don't have to
design hardware the way you design software, and vice versa.  If you are
stuck applying the same ideals for both concepts, it is harder to work
out what is right for software and what is right for hardware
separately.  And harder for experts to work efficiently within their own
area.

So what are good ideals for software?  There are many patterns to
subscribe to, but I believe https://www.gnu.org/philosophy/free-sw.html
and https://www.gnu.org/distros/free-system-distribution-guidelines.html
are worthy to aspire to.  Non-free firmware doesn't belong here.

I'm not a hardware person, so I'm less confident what good designs for
hardware should be, and it seems there is less consensus what the
desirable properties really are.  One fundamental property that I would
like is that I want to be able to examine and modify all steps that
ultimately lead to production of the hardware.  I'm sure there are more
properties that are desirable.  It is easy to see that this is a
required but not sufficient condition: otherwise you can end up
producing a closed device ecosystem like an iPhone.

> If I don't trust vendor X, then I cannot buy hardware from them independent of
> whether or not the vendor allows me to flash proprietary binary blobs from
> them. If I do trust vendor X, then why would I not trust their proprietary
> binary blobs?

One difference is that you could chose to trust their hardware (CPUs)
but don't trust their software (non-free firmware).

Consumer level protection in society is generally different when I buy a
hardware product compared to if I'm granted a license to use some
software.  If I buy a bike or helmet it has to meet certain criteria for
it to be allowed to be sold (at least where I live) but different laws
apply if I use a piece of software under some legal terms of services.

Just because I place trust in entity X for the purpose of A doesn't mean
that I necessarily must trust entity X for the purpose of B.  That is
the slippery slope that vendors want you to walk into so they can
excercise more control.

> I do not think you will find many on this list who will disagree with the
> sentiment that it would be great if we had sources, schematics etc for many
> more things. On the other hand, I don't think you can currently buy a device
> that is capable to run, for example, a modern web browser and is fully open.
> This is why I voted in the last GR as I did. I'm typing this on an MNT Reform
> which is probably among the most open computers you can buy today but the chips
> in it are *not* open silicon. Yes, it would be great if they were and it would
> be great if the firmware blobs I need would not be proprietary. But I already
> chose to trust the manufacturers of the chips in my laptop or otherwise I would
> not be typing these lines. Why would I trust the silicone from vendor X and
> distrust the firmware/microcode from vendor X? Having non-free-firmware enabled
> by default in the Debian installer just continues pursuing a trust relationship
> you already decided on entering when you bought the hardware, no?

Right, I see that if you don't appreciate the difference between these
two cases, it is reasonable and logical to regard non-free firmware as
unproblematic.

/Simon

[toc] | [prev] | [next] | [standalone]

#116291

[Multipart message — attachments visible in raw view] — view raw

Hi,

Quoting Simon Josefsson (2025-03-08 13:43:26)
> My point was that there is no reasonable way to gain confidence about
> security properties of any piece of non-free microcode.  Everyone can now
> produce AMD microcode that corrupts your machine in advanced ways that evade
> detection, but we don't know if such malicious corruption is included in the
> official microcode.  Having source code for the microcode would help gain
> confidence in it, and is the reasonable request.  If the request is denied, I
> would consider the vendor not trustworthy and look into options.

I do not understand something about this argument.

If you don't trust the vendor, then it makes no difference whether or not new
official firmware/microcode can be uploaded/flashed or not. If you don't trust
the vendor, then the initial microcode that came with your device might already
be doing things that go against your interests.

Of course we cannot have much confidence in a piece of microcode of which we do
not have the source code. But we also cannot have much confidence in a piece of
hardware with non-flashable firmware of which we don't have the vhdl/verilog
sources. So what is the difference?

If I don't trust vendor X, then I cannot buy hardware from them independent of
whether or not the vendor allows me to flash proprietary binary blobs from
them. If I do trust vendor X, then why would I not trust their proprietary
binary blobs?

I do not think you will find many on this list who will disagree with the
sentiment that it would be great if we had sources, schematics etc for many
more things. On the other hand, I don't think you can currently buy a device
that is capable to run, for example, a modern web browser and is fully open.
This is why I voted in the last GR as I did. I'm typing this on an MNT Reform
which is probably among the most open computers you can buy today but the chips
in it are *not* open silicon. Yes, it would be great if they were and it would
be great if the firmware blobs I need would not be proprietary. But I already
chose to trust the manufacturers of the chips in my laptop or otherwise I would
not be typing these lines. Why would I trust the silicone from vendor X and
distrust the firmware/microcode from vendor X? Having non-free-firmware enabled
by default in the Debian installer just continues pursuing a trust relationship
you already decided on entering when you bought the hardware, no?

Thanks!

cheers, josch

[toc] | [prev] | [next] | [standalone]

#116294

[Multipart message — attachments visible in raw view] — view raw

On Sat, Mar 08, 2025 at 02:51:29PM +0100, Johannes Schauer Marin Rodrigues wrote:
> Hi,
> 
> Quoting Simon Josefsson (2025-03-08 13:43:26)
> > My point was that there is no reasonable way to gain confidence about
> > security properties of any piece of non-free microcode.  Everyone can now
> > produce AMD microcode that corrupts your machine in advanced ways that evade
> > detection, but we don't know if such malicious corruption is included in the
> > official microcode.  Having source code for the microcode would help gain
> > confidence in it, and is the reasonable request.  If the request is denied, I
> > would consider the vendor not trustworthy and look into options.
> 
> I do not understand something about this argument.
> 
> If you don't trust the vendor, then it makes no difference whether or not new
> official firmware/microcode can be uploaded/flashed or not. If you don't trust
> the vendor, then the initial microcode that came with your device might already
> be doing things that go against your interests.

Trust in wendors (actually also their trustworthiness) is a function of
time. Remember when Github was bought by Microsoft? Remember when Twitter
was bought by -- uh -- whatever?

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#116301 — Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion

[Multipart message — attachments visible in raw view] — view raw

Am Samstag, dem 08.03.2025 um 14:51 +0100 schrieb Johannes Schauer
Marin Rodrigues:
> If you don't trust the vendor, then it makes no difference whether or
> not new official firmware/microcode can be uploaded/flashed or not.
> If you don't trust the vendor, then the initial microcode that came
> with your device might already be doing things that go against your
> interests.

The trust relationships are more complex than you put it. You have to
trust the chip vendors, the OEMs, the merchants, the delivery company,
the hotel room service etc. etc.
Since Snowden, we know that custom hardware bugs installed by anyone in
the supply chain are a real thing. The recommendation for risk groups
like journalists and lawyers nowadays is to buy random hardware from
the store and pay with cash.
However, I agree with you that we do not have a lot of options when it
comes to affordable consumer hardware. Even the various projects which
try to create openness still depend on proprietary firmware.
The situation is improving compared to what it used to be, but we still
have a long way to go.

Regards
Stephan

[toc] | [prev] | [next] | [standalone]

#116293 — Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion

[Multipart message — attachments visible in raw view] — view raw

The ideal laptop in my dreams is running pure Debian on a RISC-V CPU,
and all firmware from BIOS/EFI to peripheral devices has the source
code available with a license which allows the free-software community
to maintain it and remove undesired features.

Unfortunately, even though we are getting closer every year, we do not
have such hardware yet for the greater market for a reasonable price.
If you want to run an Intel- or AMD-based laptop, you have no choice
but to run their firmware, BIOS, EFI, microcode etc. More firmware is
required for video and network devices. Unfortunately, you cannot run
much of it without proprietary firmware, no matter if that firmware is
on the Debian CD or not.

Please note that firmware is something different than drivers. The best
option that I see at the moment with commodity hardware is to buy
hardware which does not require proprietary drivers. So at least the
main CPU and memory is free from undesired code. This is much easier
today then it used to be. I run my primary workstations without any
proprietary driver, application or library for years.

I really feel with you. I really wish there were more options without
proprietary firmware. But I not see any options.

The POWER9-based Raptor systems are advertised with free firmware, but
they use AMD video cards and Broadcom Ethernet. So I think that what
they mean by free firmware only applies to the BIOS/EFI. The coreboot
and libreboot projects also need some blobs for Intel and AMD based
systems.

Microcode is fortunately a thing of the past. It is an idea from the
1960's CISC design which is uncommon and unnecessary for RISC
processors. So the most important goal is to get develop laptop with
free EFI and free video firmware.

Regards
Stephan

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web