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

Groups > linux.debian.project > #13754 > unrolled thread

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

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

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 Simon Josefsson <simon@josefsson.org> - 2025-03-08 16:30 +0100
          Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion Matthias Urlichs <matthias@urlichs.de> - 2025-04-10 11:20 +0200
            Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion <tomas@tuxteam.de> - 2025-04-10 14:00 +0200
            Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion Simon Josefsson <simon@josefsson.org> - 2025-04-10 14:00 +0200
            Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion Henrik Ahlgren <pablo@seestieto.com> - 2025-04-10 14:00 +0200
        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

#13754 — 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]

#13756

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]

#13757

[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]

#13758

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]

#13759

[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]

#13786

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

On 08.03.25 15:36, Simon Josefsson wrote:
> One difference is that you could chose to trust their hardware (CPUs)
> but don't trust their software (non-free firmware).

True. But so, again, what's the material difference between "the 
firmware is baked into the hardware and cannot be changed" vs. "the 
firmware can be updated"?

Answer: there isn't one. They're both software, except that the vendor 
can choose to fix bugs on the latter. Nothing the FSF wrote or can 
possibly write changes this basic fact.

As a customer, which most of us are by necessity, simply because making 
hardware is a lot more expensive than coding, I am strictly worse off 
with ROM firmware. Why should I even report a bug to the manufacturer 
when that's of no benefit to me unless I toss out the buggy hardware and 
buy all-new stuff? Why should I ask the manufacturer to please open up 
their sources, maybe starting off with hardware that is no longer 
produced anyway, when I can't actually *use* the newly-open-sourced code 
for anything?

There was and still is no advantage to not shipping firmware with 
Debian, other than lofty philosophical principles and/or moral purity. 
If you decide not to buy hardware that requires loadable firmware you'll 
do that whether or not Debian also supports devices you won't buy. If I 
get my hands on hardware that won't work without it I can always install 
some other distribution instead of Debian, but I'm very unlikely to toss 
the hardware in question into the recycling bin and buy something that does.

Summary: We should, and in fact decided to (last time this came up), be 
pragmatic and leave the philosophy to the FSF.

My personal opinion: You want open hardware? go and build some yourself. 
That's the way how we got free/libre software, after all.

-- 
-- regards
-- 
-- Matthias Urlichs

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

#13787

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

On Thu, Apr 10, 2025 at 10:06:12AM +0200, Matthias Urlichs wrote:
> On 08.03.25 15:36, Simon Josefsson wrote:
> > One difference is that you could chose to trust their hardware (CPUs)
> > but don't trust their software (non-free firmware).
> 
> True. But so, again, what's the material difference between "the firmware is
> baked into the hardware and cannot be changed" vs. "the firmware can be
> updated"?

The manufacturer might fall prey for a hostile takeover by Evil
Overlord (cf. Twitter/X). Or might decide to not not be evil
anymore (cf. that other... whatsitsname?). Or State Agency A
might lean on the manufacturer to start doing things.

If you are in the firmware upgrade treadmill, the characteristics
of your "contract" are definitely different.

Now if you manage to hack your way into installing your own firmware,
more power to you, but more and more this happens in spite rather
than because of the manufacturer.

Swords, edges and that :)

Cheers
-- 
t

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

#13788

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

Matthias Urlichs <matthias@urlichs.de> writes:

> On 08.03.25 15:36, Simon Josefsson wrote:
>> One difference is that you could chose to trust their hardware (CPUs)
>> but don't trust their software (non-free firmware).
>
> True. But so, again, what's the material difference between "the
> firmware is baked into the hardware and cannot be changed" vs. "the
> firmware can be updated"?
>
> Answer: there isn't one. They're both software, except that the vendor
> can choose to fix bugs on the latter.

I don't think that is the only answer.  I believe there is a significant
different between these two cases from, e.g., a consumer freedom
perspective (accepting a software EULA compared to purchasing a physical
component).  As far as I can tell, you wouldn't agree.  The arguments
have been made many times already, so repeating them probably won't
convince either of us.  I think both viewpoints are reasonable
positions, but they lead to different conclusions how to deal with
non-free firmware: either reject it as being non-DFSG, or accept
treating as an really-part-of-the-hardware-but-wasn't exception.

> My personal opinion: You want open hardware? go and build some
> yourself. That's the way how we got free/libre software, after all.

I believe almost all free/libre software were created on closed
hardware, and often using non-free operating systems.  So I don't think
open hardware is a requirement for free software.

/Simon

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

#13789

Matthias Urlichs <matthias@urlichs.de> writes:

> On 08.03.25 15:36, Simon Josefsson wrote:
>> One difference is that you could chose to trust their hardware (CPUs)
>> but don't trust their software (non-free firmware).
>
> True. But so, again, what's the material difference between "the
> firmware is baked into the hardware and cannot be changed" vs. "the
> firmware can be updated"?
>
> Answer: there isn't one. They're both software, except that the vendor
> can choose to fix bugs on the latter.

One plausible argument is that if the vendor is capable of resolving
bugs in writable firmware, it also suggests that a targeted attack is
considerably easier than with hardware, which can presumably be trusted
to remain identical, unless one is a significant target.

However, for the majority of typical users, having the most recent
microcode/firmware is likely a significant advantage for security, even
if it is some non-free binary blob (usually not even using the user
facing ISA that the user can understand).

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

#13760

[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]

#13761

[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] | [standalone]

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

csiph-web