|
|
Log in / Subscribe / Register

Debian to vote on its firmware path

By Jake Edge
August 30, 2022

Dealing with the non-free firmware that is increasingly needed to install Debian has been a hot topic for the distribution over the past few months. The problem goes back further still, of course, but Steve McIntyre re-raised the issue in April, which resulted in a predictable lengthy discussion thread on the debian-devel mailing list. Now McIntyre has proposed a general resolution (GR) with the intent of resolving how to give users a way to install the distribution on their hardware while trying to avoid trampling on the "100% free" guarantee in the Debian Social Contract. Finding the right balance is going to be tricky as is shown by the multiple GR options that have been proposed in the discussion.

The basic problem is that the use of downloadable firmware in computer systems is on the rise and most of that firmware is not free software. The official Debian installer only incorporates free software (and firmware), which leads to serious problems for many users. McIntyre said in April:

Today, a user with a new laptop from most vendors will struggle to use it at all with our firmware-free Debian installation media. Modern laptops normally don't come with wired ethernet now. There won't be any usable graphics on the laptop's screen. A visually-impaired user won't get any audio prompts. These experiences are not acceptable, by any measure. There are new computers still available for purchase today which don't need firmware to be uploaded, but they are growing less and less common.

Currently, the Debian installer (sometimes abbreviated "d-i") image only includes packages from the official "main" repository that consists of software and firmware which conforms to the Debian Free Software Guidelines (DFSG). Obviously, main does not include the non-free firmware, which lives in the "non-free" repository instead. The same team that creates the official installer images also creates unofficial, non-free images, which is what most users actually need to install the distribution. The Debian community would much prefer not to have to provide the non-free version, but that is not really an option in today's hardware world—at least if the project wants users to actually be able to install and use Debian.

Beyond starting the mailing-list discussion, McIntyre also gave a talk at DebConf in July. One of the problems he had identified is that when users install with the non-free installer, it enables the non-free repository on their systems. That could well mean that those users unknowingly install additional non-free software simply because the Debian package manager (APT or something built on top of it) makes it directly available. That particular problem could be solved by creating a separate non-free-firmware repository; that repository was created as part of the work done during DebConf, though there is still more to do to use it in Debian.

Proposal

So McIntyre has proposed a GR with a single option; based on a suggestion by Russ Allbery back in April, McIntyre thinks it is "better to leave it for other people to come up with the text of options that they feel should also be on the ballot". His option is to include the non-free-firmware packages in the official installer, but to provide ways to inform users about the type of firmware being used and to give them ways to disable the non-free functionality and installation if desired. If that should pass, there would only be a single installer, so the "fully free" installer would no longer be built.

The proposal immediately elicited far more seconds than required (16 are shown on the GR page and five are needed). Naturally, it also drew some questions and comments, as well as some additional proposals for the ballot. Timo Lindfors asked for some additional information to be made available to users; for example:

As it is pretty impossible to write a clear definition of firmware, we should require packages in non-free-firmware to clearly explain where the code will get executed to allow people to make informed decisions. Some people are more ok with having code run on an external device than on the main CPU.

Lindfors also wanted the project to keep producing the fully free installer and to clearly distinguish between the two installers. McIntyre was amenable to adding firmware descriptions along the lines of what was requested, but thought that Lindfors's other requests were better handled with further ballot options; "I imagine that you will quite easily get seconds here". Wouter Verhelst wondered about enabling the non-free-firmware repository on installed systems by default. He thinks that only makes sense "if the installer determines that packages from that component are useful for the running system (or if the user explicitly asked to do so)". McIntyre agreed, saying that his proposal text was unclear; he provided some modified text that would make that clearer.

But Ansgar Burchardt thought that it made sense to enable non-free-firmware even if the installer did not need it. Detachable devices (e.g. USB) might require firmware, for example. "For the same reason the system should probably install all (reasonable) firmware by default, just like we install all kernel drivers even for devices that are not present on the target system."

Simon Richter wondered whether McIntyre's proposal also required changing the Debian Social Contract (DSC); he pointed to the first section of the contract ("Debian will remain 100% free") and suggested that an official installer with non-free firmware would violate that. He also alluded to section five, which allows for the non-free and contrib repositories, but not as "part of Debian". Some thread participants thought that the final line of section one ("We will never make the system require the use of a non-free component.") was not being violated by the proposal. But section five seems more problematic because it clearly says that non-free, thus by extension non-free-firmware, is not part of the Debian system, so how could an official installer incorporate that? As Simon Josefsson put it: "what is being proposed here is to replace our current DSC-compatible free software installer images with non-free. That goes significantly further than what the spirit of DSC§5 suggests."

Tobias Frost disagreed because there was no requirement that the non-free firmware be used; "there are just additional bits in there which help people to actually be able to install Debian on some modern machines". As might be guessed, others disagreed, but there are also some questions of what the majority requirements for passing the GR would be; the Debian Constitution requires a 3:1 supermajority for changing either the DSC or DFSG (the Constitution, too, for that matter). Josefsson is worried that those requirements may not be followed:

I believe it would be bad for the project if the supermajority requirements of changing a [foundational] document is worked around by approving a GR vote with simple majority that says things contrary to what the DSC says.

Project secretary Kurt Roeckx said that he had no plans to require a 3:1 supermajority for anything proposed so far, since none targets changing the social contract. He does not think that the secretary has the power to impose the supermajority requirement on the vote based on their interpretation of the proposal, though that might result in something of a mess. If a GR passes with a regular majority and might conflict with DSC, DFSG, or Constitution, "the Secretary might have to decide if it conflicts or not, and if it conflicts void the GR".

For the purposes of putting the firmware question to rest for good, Allbery would like to see proposals that change the social contract and thus require a 3:1 supermajority. A simple addition to section five allowing non-DFSG-compliant firmware in the installer would suffice.

The failure mode that I'm worried about here is that a ballot option passes expressing a position that we should include non-free firmware but since it doesn't explicitly update the Social Contract some folks who disagree with this direction for Debian continue to believe doing so is invalid and we don't actually put the argument to rest. Also, if the 3:1 majority option doesn't pass but a 1:1 option that doesn't require a supermajority does pass, that's also useful information. (For example, I believe that would imply that such an installer has to continue to be labeled as unofficial and not a part of the Debian system, since I think that's the plain meaning of point 5 of the Social Contract.)

Other options

Two other proposals have been posted and seconded, and there is a third that is in an indeterminate state at this point, but may well make the GR ballot; it is also not impossible that another option or three could crop up before the discussion period ends on September 3. Gunnar Wolf simply proposed ensuring that both installers would continue to be built, though the non-free version would be highlighted:

Images that do include non-free firmware will be presented more prominently, so that newcomers will find them more easily; fully-free images will not be hidden away; they will be linked from the same project pages, but with less visual priority.

That proposal (proposal B on the GR page) garnered nine seconds (including McIntyre), but also drew another proposal that is seemingly in procedural limbo as of this writing. Josefsson proposed something that is effectively the antithesis of McIntyre's (proposal A) and proposal B; it also embodies the status quo at this point by forcing any installer with non-free firmware to be "unofficial" and to not be distributed as part of Debian. It appears to have been seconded enough times, though some of those seconds are not because the person agrees with Josefsson, they simply think that the option should be available to the voters. Meanwhile, there was a procedural hiccup and the proposal does not appear on the GR page (as of this writing).

That leaves proposal C, which is a simplified statement in support of non-free firmware for the installer that leaves out the details in McIntyre's and Wolf's proposals; it was proposed by Bart Martens and is just one sentence long:

The Debian project is permitted to make distribution media (installer images and live images) containing packages from the non-free section of the Debian archive available for download alongside with the free media in a way that the user is informed before downloading which media are the free ones.

It was seconded by five developers, including McIntyre again. In his message seconding it, Stefano Zacchiroli noted that it perhaps sidesteps conflicts with the social contract; making users choose is less than optimal, but may open some eyes as well:

Rationale: while it is not lost on me that in terms of usability having to choose between two options is a net loss for newcomers, I think this might be the only way to not run afoul of the Social Contract. Also, I think that on users that are even a little bit more knowledgeable and come to Debian for software freedom reasons, this choice might carry some real educational value (on how bad the consumer hardware market is these days, mostly).

There is a danger to pushing the free installer, which came up earlier in the thread, however. Since there are few systems that can actually work without the non-free firmware, using the free installer will lead to user unhappiness, which may impact more than just Debian's reputation, as Ted Ts'o noted:

Whether we recommend the one with non-free firmware or not (some have proposed that the "free" installer would have "visual priority", whatever that means), I suspect there will be various Linux newbie or FAQ's, external to Debian, that will warn users that the using the "free" installer will just cause them pain and frustration.

So there may be some unintended consequences where new users may associate "100% free software" with "not functional" and "induces pain and frustration", such that it might end up *hurting* the cause of free software.

The voting will presumably start in early September and a resolution may come by mid-month. The constitutional question is cogent, so Allbery's suggestion to explicitly have an option that changes the social contract seems like a good one. It would be ugly to see something pass and then to get invalidated; even if it passed by 3:1 or more, which is a high bar to surmount, the question of conflicting language in the social contract would still linger. At a minimum, the GR will help determine the mood of the project with respect to non-free firmware in the installer, which is definitely a good start.


to post comments

Debian to vote on its firmware path

Posted Aug 31, 2022 6:43 UTC (Wed) by patrakov (subscriber, #97174) [Link] (28 responses)

I think that it no longer makes sense to distribute installers without firmware when targeting bare metal - at the very least, because of the security and correctness fixes in the CPU microcode. There is, however, an important class of platforms that don't need firmware: virtual machines. And therefore I think that the free installer has its place - it just has to be labelled accordingly, as a way to save some megabytes from the download if the target would be a virtual machine.

Debian to vote on its firmware path

Posted Aug 31, 2022 8:09 UTC (Wed) by IanKelling (subscriber, #89418) [Link] (23 responses)

> I think that it no longer makes sense to distribute installers without firmware when targeting bare metal - at the very least, because of the security and correctness fixes in the CPU microcode

No, that is security paranoia. Many people, like me, run free distros and don't accept nonfree microcode updates and we haven't had security breaches.

Debian to vote on its firmware path

Posted Aug 31, 2022 8:57 UTC (Wed) by bluca (subscriber, #118303) [Link]

...that you know of. Obviously you can cross the road blindfolded and with earplugs, but the fact that you haven't been ran over by a lorry doesn't mean it's safe, it's just survivorship bias.

Debian to vote on its firmware path

Posted Aug 31, 2022 9:42 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (16 responses)

> we haven't had security breaches.

In all of these scenarios there's a balance between the effort required to take advantage of the vulnerability and the attractiveness of the target. Most of the vulnerabilities mitigated by CPU microcode updates are reasonably high effort to take advantage of, which means that it's just not worth the effort for most people. So, congrats, you're not interesting (and, to be fair, nor am I). That doesn't mean that nobody is, and free software needs a reasonable answer for people who *are* sufficiently interesting because right now the FSF doesn't have one.

Debian to vote on its firmware path

Posted Aug 31, 2022 10:33 UTC (Wed) by Wol (subscriber, #4433) [Link]

Microcode updates also fix accidental DDoS!

My home system is a Ryzen 3000, for which I need to investigate and fix regular freezes. It's just not annoying enough for me take the inevitable flak from the wife.

I SUSPECT it may be the RDRand hardware bug.

Cheers,
Wol

Debian to vote on its firmware path

Posted Aug 31, 2022 18:40 UTC (Wed) by IanKelling (subscriber, #89418) [Link] (14 responses)

> free software needs a reasonable answer

I think there are like 5 reasonable answers. The first one that comes to mind is that there are lots of CPUs which can be used in freedom and don't have any nonfree microcode updates at all, and some don't even have updateable microcode.

Debian to vote on its firmware path

Posted Aug 31, 2022 19:17 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (4 responses)

And how do you fix security-critical issues in those CPUs?

Debian to vote on its firmware path

Posted Sep 6, 2022 22:41 UTC (Tue) by IanKelling (subscriber, #89418) [Link] (3 responses)

The bugs don't make using the cpu insecure, they change the security assumptions, you can operate within those assumptions, migrate certain certain use cases to a different cpu, there are various solutions. Of course those bugs existed the whole time and security is not a binary.

Debian to vote on its firmware path

Posted Sep 6, 2022 22:54 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (2 responses)

But if a CPU allows (even proprietary) microcode updates that provide mechanisms to mitigate the security flaws, your argument is that it's still preferable from a freedom perspective to use one that doesn't?

Debian to vote on its firmware path

Posted Sep 7, 2022 6:37 UTC (Wed) by IanKelling (subscriber, #89418) [Link] (1 responses)

Free microcode updates would be good. Yes, most people are probably better off from a software freedom perspective with cpus that have no microcode at all. Afaik, those have historically had less security flaws too. But there are some freedom related reasons a person could be an exception. I started to write them down, but it got a bit long and I need to stop. I'll try to finish in the next week and post.

Debian to vote on its firmware path

Posted Sep 8, 2022 2:35 UTC (Thu) by pabs (subscriber, #43278) [Link]

There has been research into modifying CPU microcode that might eventually allow free microcode:

https://www.usenix.org/conference/usenixsecurity17/techni...
https://github.com/RUB-SysSec/Microcode

It is very likely that the CPUs don't have enough storage to update *all* of the non-free microcode in ROM, but patching a small part of it might be doable. This is definitely the case for other "free" firmware too, some of the WiFi/GSM firmware is like that.

Debian to vote on its firmware path

Posted Aug 31, 2022 19:51 UTC (Wed) by pizza (subscriber, #46) [Link] (8 responses)

> The first one that comes to mind is that there are lots of CPUs which can be used in freedom and don't have any nonfree microcode updates at all, and some don't even have updateable microcode.

By your definition, a device that ships with firmware in mask ROM (or the modern equivalent of a large array of OTP) is somehow "freer" than a device that has any means of being updated. That is... farcical.

Debian to vote on its firmware path

Posted Aug 31, 2022 23:40 UTC (Wed) by IanKelling (subscriber, #89418) [Link] (7 responses)

> is somehow "freer"

I would say it is incapable of infringing on my software freedom. Is a wall "freer" than a jail cell door I'm locked behind? I can't open the wall, nor can open the jail cell door. They clearly bring different ethical concerns. Sure, you can say "look at all the ways they are the same! Treating them different is a farce." And I think, well, if you really really want to see them the same, sure, go ahead, but I think that is obviously wrong. Getting away from metaphor, I understand that in theory my intel cpu is running microcode, but it is an inseparable part of hardware, and in fact, there is no way for me to access that microcode whatsoever. I can't get a copy from my own cpu or anywhere on the internet. When intel offers for me to download program with a restrictive license and no source code, that is obviously a different ethical situation, even if it happens to be "microcode". FSF has long explained this ethical distinction, for example in https://www.fsf.org/campaigns/free-bios.html.

Debian to vote on its firmware path

Posted Aug 31, 2022 23:42 UTC (Wed) by IanKelling (subscriber, #89418) [Link]

without the period so the link works:
https://www.fsf.org/campaigns/free-bios.html

Debian to vote on its firmware path

Posted Sep 1, 2022 13:44 UTC (Thu) by IanKelling (subscriber, #89418) [Link]

Adding to my previous comment: of course it would be better if the builtin version was released as free software, and if someone wants to only run chips that have free designs and free microcode, good for them. I hope everyone can do that someday.

Debian to vote on its firmware path

Posted Sep 3, 2022 1:38 UTC (Sat) by KJ7RRV (subscriber, #153595) [Link] (4 responses)

Device with nonrewritable, nonfree firmware (device C):

* Manufacturer cannot rewrite firmware
* You cannot rewrite firmware

Device with rewritable, nonfree firmware (device B):

* Manufacturer can rewrite firmware, but only with your permission (you can refuse the update)
* You cannot run your own firmware, unless and until someone reverse-engineers the device and writes FOSS firmware; at that point you can run custom firmware

Device with rewritable, free firmware (device A):

* Manufacturer can rewrite firmware, but only with your permission (you can refuse the update)
* You can run your own custom firmware

Obviously, A is preferable over B or C, but doesn't B give more freedom than C because there is at least the possibility of using free firmware in the future?

Debian to vote on its firmware path

Posted Sep 3, 2022 11:35 UTC (Sat) by mpr22 (subscriber, #60784) [Link]

It does, under a general-purpose worldview.

However, the FSF's particular stance is, as I understand it:

1. If the firmware cannot be replaced without making physical changes to the hardware (e.g. pulling the mask ROM and fitting a new one, or soldering patch wires to the board to reconnect the programming voltage connection for the EEPROM), then it is part of the hardware, and thus outside their wheelhouse.

2. If the firmware can be replaced by software means (e.g. it's in an EEPROM and the programming voltage is permanently available or software-controlled), then it is software, and thus inside their wheelhouse.

Debian to vote on its firmware path

Posted Sep 5, 2022 8:39 UTC (Mon) by geert (subscriber, #98403) [Link] (1 responses)

Can you refuse the upgrade?

Option B gives the manufacturer the power to make the device unusable, which is not the case with option A.

Debian to vote on its firmware path

Posted Sep 5, 2022 10:26 UTC (Mon) by Wol (subscriber, #4433) [Link]

Sony PS/2 and a warranty repair?

Cheers,
Wol

Debian to vote on its firmware path

Posted Sep 6, 2022 21:29 UTC (Tue) by IanKelling (subscriber, #89418) [Link]

> Obviously, A is preferable over B or C, but doesn't B give more freedom than C

It is fine to prefer C over and A and B. I would for my toaster which is simple and has no networking ability, and I wouldn't really characterize the difference as losing an important freedom compared to B. Beyond that I don't have time to give a comprehensive answer. I would also mention that there is some widespread firmware which can only be updated with encrypted & cryptographically signed version where only the manufacturer has the key so it is almost impossible to reverse engineer, so doesn't fit into your categories.

Debian to vote on its firmware path

Posted Aug 31, 2022 13:51 UTC (Wed) by jbicha (subscriber, #75043) [Link]

Why do you use CPUs with nonfree microcode but refuse to accept manufacturer updates of the nonfree microcode?

Debian to vote on its firmware path

Posted Aug 31, 2022 14:53 UTC (Wed) by developer122 (guest, #152928) [Link] (1 responses)

Excuse me while I count the number of times your CPU has accidentally written a byte in the wrong place. Turns out mine used to do it all the time before applying a microcode patch that fixed bad TLB behavior.

You have absolutely no idea what problems exist in the nonfree microcode you bought with your processor. Refusing to patch it is simply pretending that it doesn't exist and does your freedom zero favors.

Debian to vote on its firmware path

Posted Aug 31, 2022 23:48 UTC (Wed) by IanKelling (subscriber, #89418) [Link]

> Refusing to patch it is simply pretending that it doesn't exist

I'm not pretending. Let's not forget that Debian refused to distribute a microcode update and sparked a change in Intel's microcode license terms: https://www.techspot.com/news/76109-intel-no-more-benchma...

Debian to vote on its firmware path

Posted Aug 31, 2022 21:40 UTC (Wed) by dvrabel (subscriber, #9500) [Link]

If you have systems that store personaly indentifyable information (like email addresses or other contact information), then you have a duty of care (and a legal requirement is many jurisdictions) to ensure the security of that data. I don't think crossing your fingers and relying on "herd immunity" is really an acceptable risk management strategy.

Debian to vote on its firmware path

Posted Aug 31, 2022 23:00 UTC (Wed) by moxfyre (guest, #13847) [Link]

> Many people, like me, run free distros and don't accept nonfree microcode updates and we haven't had security breaches.

Hmm… that strikes me as a somewhat arbitrary and bizarre distinction.

In reality you *have* “accepted” whichever post-manufacturing microcode updates the CPU vendor or OEM applied to the CPU prior to putting it in a box on a shelf, or shipping the device to you.

You did stop “accepting” the microcode updates after the CPU was in your hands and under your control.

That's fine (I don't believe anyone should be forced to get software updates that they don't think they want and/or need) but… I wouldn't be under any illusions that your device hasn't received any (non-free) microcode updates.

I worked on the hard-hard-hardware side of CPU production for many years, and there came to appreciate the almost unbelievably large number of software-y/firmware-y modifications made to integrated circuits after their physical manufacturing.

Debian to vote on its firmware path

Posted Aug 31, 2022 20:09 UTC (Wed) by bartoc (guest, #124262) [Link] (3 responses)

tbf, especially for modern laptops, distributing Wireless PHY firmware, even if nonfree (and it all is nonfree) makes sense. After all even if a vendor _wanted_ to make their wifi firmware fully free they likely could not, the FCC does not look kindly on devices that allow fully free firmware. This stance from the FCC is really rather annoying, and ideally would be changed, but not including wifi firmware in Debian in the meantime is unlikely to change it and will make improvements in other areas harder. After all, if you want to make Debian work great on your hardware, but know making the wifi work will call down the wrath of the FCC on your device, then you may not even bother with anything else.

Debian to vote on its firmware path

Posted Aug 31, 2022 21:32 UTC (Wed) by brunowolff (guest, #71160) [Link] (1 responses)

There is free firmware for b43 and ath9 wireless devices. I think the b43 firmware has some issues as development stopped before the bugs got shaken out. But you can still use it to get a good enough connection to switch over to Broadcom's firmware.

Debian to vote on its firmware path

Posted Sep 1, 2022 6:51 UTC (Thu) by johill (subscriber, #25196) [Link]

Last I checked, b43 firmware basically still copied chunks of disassembled code from Broadcom's firmware though. Not that it matters much in practice (Broadcom isn't going to care and regulatory-wise those firmware images weren't doing anything anyway, they're just doing lower MAC processing), but ... calling it fully free when there are chunks of "nobody understands this part" in there is a bit of a stretch?

Happy to be proven wrong if they fixed it somehow in the 10+ years I wasn't looking.

Debian to vote on its firmware path

Posted Sep 1, 2022 1:42 UTC (Thu) by pabs (subscriber, #43278) [Link]

Debian already includes free WiFi firmware for ath9k_htc and carl9170 based devices. We are missing the OpenFWWF one for b43 devices though.

https://wiki.debian.org/Firmware/Open#Radio

Debian to vote on its firmware path

Posted Aug 31, 2022 7:47 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

Personally I think the unofficial installer workaround to the issue is just as much a breach of the principle of only distributing free software as a single installer with clearly labelled non-free options would be. The only difference would be potential distribution restrictions in the non-free firmware. Since a single installer is likely less work and easier for the users I would prefer that route.
For most versions of the installer it would probably be possible to download the vast majority of the non-free firmware anyway (all but network adapter and possibly CPU), avoiding the distribution issue.

Debian to vote on its firmware path

Posted Aug 31, 2022 15:35 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

You really do want to have basic graphics and sound (for visually impaired users) working before you go to download stuff. The user should know what you are downloading and where you are downloading it from, as well as how big it is and how long you think it will take.

Debian to vote on its firmware path

Posted Aug 31, 2022 8:01 UTC (Wed) by IanKelling (subscriber, #89418) [Link] (51 responses)

In general, I think segregating nonfree firmware into a different repo section is a good idea because it can help people who use it to avoid other nonfree software. But, making that "official", I don't agree with.

This article doesn't provide any arguments /for/ treating nonfree software in a way that promotes software freedom, such as excluding it, offering it less prominently, warning about it, etc, so I will provide some.

> non-free firmware that is increasingly needed to install Debian

Citation needed, it likely depends on your perspective. For every Debian release ever made, Debian works on more total models of hardware than ever before. There are more vendors that explicitly support it than ever before. There are millions of not quite brand new computers you can buy second hand, which often end up in the trash and are well supported by Debian. Debian having some commitment to free software has helped make a lot of free software come into existence. Phones are the primary computers for most of the world and Debian doesn't work on 99.9% of them, but there is nothing "increasing" in that existing trend. Maybe there have been some vendors of some very new computers that have more freedom problems than they did in the past, but standing up for your values often only matters when they are tested, not when things are working out well. "These experiences are not acceptable, by any measure." I have a measure: Debian had way worse hardware support than this so called currently "not acceptable" level for many years, and people accepted it without Debian abandoning its values.

The article inaccurately describes "the basic problem." The article frames it as if this software fell from the sky, and it is Debian causing the problem for users. No, the computer makers are mistreating users by denying them freedom, keeping hardware specs secret, and in the process, causing pressure on Debian to cooperate and help them in that mistreatment. If Debian decides to change and make nonfree software "official" with the most prominence, it will send a message to them: they succeeded in pressuring Debian into accepting it and there is more reason for them to keep making nonfree software, less reason to make it free.

I find Ted Tso's quote, and the article's agreement that "there is a danger to pushing the free installer" to be ridiculous. Debian has given the official free installer more prominence and has "pushed it" for its entire history as far as I can tell. The article and quote is misleading by suggesting Debian would be doing something new and dangerous. If there is any danger, it would be due to the change toward making nonfree images more prominent and official, for example, would there be less effort toward making the free one work on more hardware? People have been making arguments for Debian to be like other distros and embrace nonfree software for all of its 28 year history by saying nonsense things like Debian is only hurting itself by doing anything to stand up for software freedom. It is unfortunate to see that attitude over represented in an lwn article. If anything, there are lots of ways for Debian to promote software freedom more than it does. This article comes to mind: https://www.gnu.org/philosophy/install-fest-devil.en.html , and of course there are ways for it to get closer to https://www.gnu.org/distros/free-system-distribution-guid... .

Debian to vote on its firmware path

Posted Aug 31, 2022 8:44 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (49 responses)

> Citation needed, it likely depends on your perspective.

In my personal experience: I haven't had a network card (wifi or eth) working without non-free firmware for my past 4 computers (about 11 years). So the machine works fine, but with no internet the use is a bit limited.

While indubitably there are machines that can work without such firmware, they are not common.

I can use debian because I know I have to look for the hidden non-free installer .iso via google. But someone who is new to debian will not know about this.

The installer does a very good job at letting people side load firmware, but one requires a second computer and a second USB drive.

Why must we gatekeep most people from using debian because they bought the wrong machine (I am sceptical of the claims that there is such a thing as a right machine)? Is it really so important to make most newcomers unable to install debian? What does this achieve?

Debian to vote on its firmware path

Posted Aug 31, 2022 9:25 UTC (Wed) by amacater (subscriber, #790) [Link] (45 responses)

A lot of the issues in these responses have been raised over in debian-vote or in discussions over the last few years. "Fully free machines with free firmware" exist: they are either incredibly old (Thinkpad X200 series), have had firmware disabled (any Thinkpad much later running on coreboot) or are incredibly expensive (Raptor's Talos series starting at about USD 9k).
Likewise, fully free distros exist: often stripping firmware and drivers out of Debian or Ubuntu and then relying on the subset of hardware that these will fit and then being behind the curve on updates.

Debian _does_ work on a huge variety of hardware: the problem is that most laptops from the last few years require at least
WiFi - many users have to install with no connectivity other than WiFi. There's always been the problem of network card drivers, even on servers. Now we have the problems of signed firmware and audio not working out of the box, for example.

Steve's separation of "firmware" and other non-free (drivers etc.) helps clarify what we have (and also means that people will be able to install *just* firmware if that's what is needed. [The fully free installer is ideal for virtual machines where you are already sitting on firmware/emulated firmware so don't have a problem.]

Idealism is fine: buying and using FSF RYF hardware is possible for some of us. If you want to keep laptops out of landfill, keep servers running once the manufacturers initial paid support is gone, or whatever, there has to be something suitable - this may be it. [Full disclosure: I work with Steve on the releases of Debian installation media. I've therefore installed Debian a couple of thousand times using the fully free installer. I have non-free firmware on all my machines because I need them to work. I'm fully familiar with all variations of the arguments round the propriety of this]

Debian to vote on its firmware path

Posted Aug 31, 2022 9:33 UTC (Wed) by pabs (subscriber, #43278) [Link] (20 responses)

Raptor devices start at $5k not 9k, but that is indeed quite expensive compared to other hardware. The price of freedom I guess.

I also wonder why the focus on firmware and not also on other non-free components, for example IIRC some laptop WiFi devices require non-free drivers, not just non-free firmware.

Debian to vote on its firmware path

Posted Aug 31, 2022 10:57 UTC (Wed) by chris_se (subscriber, #99706) [Link] (2 responses)

> I also wonder why the focus on firmware and not also on other non-free components, for example IIRC some laptop WiFi devices require non-free drivers, not just non-free firmware.

You could also extend that logic to e.g. NVIDIA's proprietary GPU driver, that would also count as hardware enablement.

But what if you have a piece of scientific measurement equipment that has a non-free but gratis software that talks with the hardware, but the software is more than "just" a driver, it's a graphical measurement suite? Would that also count as hardware enablement because that software is currently the only thing that can talk to that hardware? (What if that software is only available for Windows, but runs perfectly in Wine?)

I think deciding where to draw the line is not always going to be easy, so maybe it's not such a bad idea that the scope of the current proposal is limited to firmware?

Debian to vote on its firmware path

Posted Aug 31, 2022 12:36 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

For the "graphical measurement suite" my instinct is that _immediately_ that suite will prove to be inadequate in some way and we'll wish we had access to the measurements themselves directly.

Maybe, if instead it is a daemon that does magical stuff to the raw sensor data and produces output, that's an interesting problem. Because if the daemon lived inside the equipment running on a micro-controller (and is thus firmware) that seems like a minor difference. But from experience the "graphical measurement suite" is going to have a set idea of how to do science and your scientists won't like it, and this would all go much smoother if their grad student with a mediocre Python skillset could get the measurements out, rather than everybody fighting with the GUI.

This sort of thing leads to a sub-field where everybody's papers have pictures of screenshots of charts from the GUI everybody uses, and at any moment there might be a paper from somebody who decided fuck this PhD, I'm tearing the roof off, and shows actually the equipment just doesn't work properly, here it is saying a cheese sandwich is dangerously radioactive, or that dirt I found in the car park is moon dust, or detecting earthquakes when I point a green laser pointer at the case. Because the manufacturer could hide ever growing flaws in new versions of the product by just tweaking that GUI everybody trusts until there's no data just artefacts.

Debian to vote on its firmware path

Posted Aug 31, 2022 15:25 UTC (Wed) by passthejoe (guest, #156034) [Link]

If your device that requires non-free firmware doesn't stop the system from booting and getting networking, then you are free to get whatever drivers or other software you need to run an add-on device.

But the issue for me is if you can't boot or get internet, you really can't exercise any "freedom."

Debian to vote on its firmware path

Posted Aug 31, 2022 11:34 UTC (Wed) by stevem (subscriber, #1512) [Link] (13 responses)

We need to draw a line somewhere. This seems a reasonable place for me...

Debian to vote on its firmware path

Posted Sep 1, 2022 0:33 UTC (Thu) by pabs (subscriber, #43278) [Link] (4 responses)

I don't think we do, there will always be something non-free that is required for someone to install/use Debian. A laptop with a WiFi device that only has a non-free driver like broadcom-sta-dkms. With userspace block devices and CXL coming there could even be non-free storage drivers. A non-free text-to-speech system for a blind user of a language other than English or for someone who can't understand the robotic free English TTS that are in Debian. A non-free driver for an special input device for someone with a reduced motor control. A non-free speech-to-text system for someone without any limbs.

https://wiki.debian.org/wl

Debian to vote on its firmware path

Posted Sep 1, 2022 17:19 UTC (Thu) by jbicha (subscriber, #75043) [Link] (2 responses)

I thought the intent of this vote was that if the proposal won, we wouldn't have fundamental CPU, network, graphics, and sound hardware support in non-free anymore. It would either be in main or non-free-firmware.

Debian to vote on its firmware path

Posted Sep 1, 2022 17:35 UTC (Thu) by amacater (subscriber, #790) [Link]

That's more or less the sense in which I read it, yes. Interestingly, before this series of comments, I hadn't picked up that Fedora already includes fundamental firmware by default where possible.

Debian to vote on its firmware path

Posted Sep 4, 2022 11:39 UTC (Sun) by pabs (subscriber, #43278) [Link]

Ideally it would be in non-free too for backwards compatibility, but as I understand it, that won't happen.

Debian to vote on its firmware path

Posted Sep 1, 2022 17:32 UTC (Thu) by stevem (subscriber, #1512) [Link]

So there's no perfect solution here, agreed. But that shouldn't stop us from supporting a much higher proportion of user machines. Let's have some perspective please.

Debian to vote on its firmware path

Posted Sep 1, 2022 20:59 UTC (Thu) by amarao (guest, #87073) [Link] (7 responses)

The line is on CPU. If it runs on the CPU it must be free. If it runs on some axillary stuff, we care less (as long as we don't provide OS for that stuff).

Debian to vote on its firmware path

Posted Sep 1, 2022 21:50 UTC (Thu) by Wol (subscriber, #4433) [Link] (5 responses)

So what do you do about that copy of minix running on ?every modern Intel CPU?

Cheers,
Wol

Debian to vote on its firmware path

Posted Sep 2, 2022 2:54 UTC (Fri) by amarao (guest, #87073) [Link] (1 responses)

As far as I understand it runs on separate processor of different architecture and is no differ than any BMC from dell/supermicro/HP. I would like to poke around it, but it has closed source operating system and Debian is not supporting it anyway as a target. For me it's no differ from network card code or MMU code, or DIMM chip code. Some other guys code. The fact that BMC is baked into the same chip as CPU is irrelevant. It become relevant when we move into coreboot domain, but for OS, a service processor is just a hardware.

The freedom I value is ability to read and modify code for my operating system, not abstract alignment with 'everything must be opensource'.

There are two sides of opensource:
Side A: this is free code. Let's hack it together.
Side B: you, nasty vendor, must publish everything as open source because I say so.

I don't really like side B, because it's unreasonable demand from unrelated people.

Debian to vote on its firmware path

Posted Sep 2, 2022 6:22 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

Modern versions of the management engine are actually x86 based, but are part of the chipset rather than the CPU (some mobile parts have these both on the same package, but as separate dies). It's not quite the same as a BMC since it has more direct involvement in CPU bring up, but I agree that it's probably conceptually closer to that than any other category of hardware.

Debian to vote on its firmware path

Posted Sep 2, 2022 6:15 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

It runs on the motherboard chipset, not on the CPU

Debian to vote on its firmware path

Posted Sep 3, 2022 16:12 UTC (Sat) by cortana (subscriber, #24596) [Link] (1 responses)

Is that the Linux distribution's concern? They aren't shipping it are they?

(Don't tell me it's small enough to be included in the intel-microcode package!?!?)

Debian to vote on its firmware path

Posted Sep 4, 2022 0:08 UTC (Sun) by pabs (subscriber, #43278) [Link]

The only way Linux distros are involved is that if they package fwupd, then their users can easily install ME updates provided by their hardware vendor on the Linux Vendor Firmware Service.

https://fwupd.org/

Debian to vote on its firmware path

Posted Sep 3, 2022 4:10 UTC (Sat) by pabs (subscriber, #43278) [Link]

As I understand it, the CPU microcode updates will be included in the non-free installer and installed systems. Perhaps that is considered outside the CPU layers that the bootloader/OS runs on though.

Debian to vote on its firmware path

Posted Aug 31, 2022 16:09 UTC (Wed) by brunowolff (guest, #71160) [Link]

Blackbirds are available again, so you can probably put together a system for significantly less than 5k. It will still be expensive compared to common machines with similar performance.

Debian to vote on its firmware path

Posted Aug 31, 2022 22:55 UTC (Wed) by moxfyre (guest, #13847) [Link] (1 responses)

I also wonder why the focus on firmware and not also on other non-free components, for example IIRC some laptop WiFi devices require non-free drivers, not just non-free firmware.
That is true, but needing such a driver is extremely rare nowadays. I'm sure there are exceptions, but I'm not actually aware of any device that you could buy in 2022 and on which you would otherwise be able to run a desktop Linux distribution, but for the lack of a FLOSS driver in the Linux kernel.

There are a very large number of FLOSS wireless drivers integrated in the mainline Linux kernel nowadays (see https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers#Status), and almost all of the drivers that support anything newer than 802.11g require non-free firmware.

The only exceptions:

  • b43 driver supports free firmware thanks to the Herculean efforts of openfwwf (the availability of free firmware for b43 has enabled some amazingly cool research like Maranello for partial packet recovery). Downside: the free firmware can't do hardware crypto, so host CPU performance can suffer
  • ath9k (and some variants) don't require firmware; they're low-end devices that don't have on-device CPUs/MCUs, so host CPU performance can suffer
… and that's it. There are, as far as I know, simply no other FLOSS devices or drivers supporting 802.11n (released in 2009!) or newer standards that don't absolutely require non-free firmware to function.

Debian to vote on its firmware path

Posted Sep 1, 2022 0:41 UTC (Thu) by pabs (subscriber, #43278) [Link]

While doing Debian support, I have had to point users at the non-free broadcom-sta-dkms package before, so the non-free driver issue definitely does occur.

Another problem is non-redistributable firmware, in some situations the only legal way to get proprietary firmware (or other data) for your device is to extract it from the proprietary factory installed OS. I think I read that Apple ARM laptops have that issue.

https://wiki.debian.org/wl

There are other free WiFi firmware projects btw. All for very old devices and standards indeed though: open-ath9k-htc-firmware, carl9170fw, Prism54 FreeMAC

https://wiki.debian.org/Firmware/Open#Radio

Debian to vote on its firmware path

Posted Aug 31, 2022 15:57 UTC (Wed) by IanKelling (subscriber, #89418) [Link] (23 responses)

> they are either incredibly old [...] or incredibly expensive

That just isn't correct at all. https://puri.sm/ sells laptops that work with fully free Debian. I've also used a system76 10th gen intel laptop where all hardware worked perfectly with Trisquel, so it would work with Debian. I'm sure there are other recent laptops out there too.

...

> A lot of the issues in these responses have been raised over in debian-vote or in discussions over the last few years.

Quite unfortunate if you read them and left being misinformed on basic facts of the situation.

>Steve's separation of "firmware" and other non-free (drivers etc.) helps

As I said, I support that separation, but not bundled with making the nonfree firmware official and more prominent. Unfortunately, none of the voting options do that.

Debian to vote on its firmware path

Posted Aug 31, 2022 16:54 UTC (Wed) by amacater (subscriber, #790) [Link] (6 responses)

IanKelling: I'm not sure you read the sentence that was more or less first in my post about laptops with firmware intentionally disabled to run coreboot - the Purism laptop is an Intel laptop with IME which has been disabled. Fine - but it's still a laptop which contains non-free firmware - you're paying a £600 premium over a similar second hand laptop.. Likewise System76. And you're paying a significant premium to remove embedded firmware and functionality that is there within your laptop. That doesn't help the owner of whatever whose similar laptop is rescued from the landfill / the family donated a free laptop to help a child's studies or whatever.

I'm fairly familiar with basic facts here - Pabs is right about Raptor at $4.5k but that's the motherboard and two processors - no case, no memory, I think. As ever, it's all a choice - to some extent, it's idealism versus pragmatism. I'm quite pleased that Trisquel exists - I note that almost none of the other FSF-approved distributions have seen significant progress in the last couple of years and ??Hyperbola?? is moving to a BSD foundation which, if anything, cares even less about firmware freedom: if it can be distributed, it's OK to go into BSDs.

Debian to vote on its firmware path

Posted Aug 31, 2022 18:25 UTC (Wed) by IanKelling (subscriber, #89418) [Link] (2 responses)

> Fine - but it's still a laptop which contains non-free firmware

We may have had some miscommunication, thought you were replying regarding the proposed change to Debian, so that was what I was addressing. Yes, there exists lots of nonfree firmware that Debian doesn't need to distribute and they are extremely common. That is a completely uncompelling reason for Debian to promote nonfree software. That is like saying: lots of bad things are happening all the time, so I should join in.

Debian to vote on its firmware path

Posted Aug 31, 2022 18:38 UTC (Wed) by bluca (subscriber, #118303) [Link] (1 responses)

Quite the opposite. It's extremely hypocritical and downright nonsensical to worry about who is shipping what, when every single piece of hardware ships with proprietary firmware. If it's not on the motherboard (unlikely) it will be in the monitor or the keyboard or whatever else. Debian images are not pieces of art, to hang to a wall and contemplate. Without its functional purpose they are perfectly useless and have no reason to exist. And that functional purpose is to run on machines full of proprietary firmware. Being able to function, and to securely update such firmware, is so much more important than mental gymnastic about being "free".

Debian to vote on its firmware path

Posted Sep 6, 2022 21:17 UTC (Tue) by IanKelling (subscriber, #89418) [Link]

Valuing "functional purpose" above all, you can say it is a waste of time for me to vote, it won't ever change an election. Not voting in one circumstance does not make it hypocritical to vote in another.

About who ships what, of course it matters: "What they do on their own is their responsibility; what we do for them, and what we direct them towards, is ours" https://www.gnu.org/philosophy/compromise.en.html , and that article talks more about this general issue.

Debian to vote on its firmware path

Posted Sep 1, 2022 1:35 UTC (Thu) by pabs (subscriber, #43278) [Link]

I was talking about the "Talos™ II Entry-Level Developer System", which includes case and RAM, for $5k not $4.5k. Agreed this is still expensive.

https://www.raptorcs.com/content/TLSDS3/intro.html

Debian to vote on its firmware path

Posted Sep 1, 2022 10:42 UTC (Thu) by paulj (subscriber, #341) [Link] (1 responses)

Purism looks really good. They seem to be US based? Are there EU equivalents?

Vendors in this space are really worth supporting, and I think I will with my next hardware purchase later this year.

Debian to vote on its firmware path

Posted Sep 1, 2022 11:58 UTC (Thu) by brunowolff (guest, #71160) [Link]

I'd suggest looking a what Raptor is doing, especially if your interest is more toward security than freedom.
Bunny Huang is also doing some interesting development of secure portable/personal devices.

Debian to vote on its firmware path

Posted Aug 31, 2022 23:19 UTC (Wed) by moxfyre (guest, #13847) [Link] (15 responses)

>> they are either incredibly old [...] or incredibly expensive
>
> That just isn't correct at all. https://puri.sm/ sells laptops that work with fully free Debian. I've also used a system76 10th gen intel laptop where all hardware worked perfectly with Trisquel, so it would work with Debian. I'm sure there are other recent laptops out there too.

All of these debates about the relative price/availability of “computer that can run with only the official Debian image” seem to be missing the point…

It doesn’t matter whether such hardware costs $5,000 more, or $500 more, or $50 more than “typical” computers which require non-free firmware.

One of the main ways that we get more people to start using Free Software is by convincing them to install Linux (or other FLOSS operating systems) on THE COMPUTERS THEY ALREADY HAVE. Installing Slackware on my Cyrix 486-ish clone in ~1994 is how I got started with Linux. Installing Mandrake Linux on the laptop that I got at university a few years later is how I kept going with it.

Probably many of you have similar stories.

Telling people “if you wanted to use Linux, you should have bought a different computer” is going to prevent many of them from using FLOSS operating systems at all. In my opinion, it’s extremely important for desktop Linux distributions to support as much commonly-available hardware as possible, in order to lower the barriers to adoption.

Fortunately, the Linux kernel already does an amazing job of having FLOSS *drivers* for most of the desktop-centric hardware in existence, and then some. It's unfortunate that supporting some hardware (especially WiFI, graphics, cameras) requires non-free binary blobs to be loaded onto auxiliary CPUs/MCUs, but I really don't think we should be putting this up as a purity test for Linux distributions.

Debian to vote on its firmware path

Posted Sep 1, 2022 1:18 UTC (Thu) by khim (subscriber, #9252) [Link] (11 responses)

> One of the main ways that we get more people to start using Free Software is by convincing them to install Linux (or other FLOSS operating systems) on THE COMPUTERS THEY ALREADY HAVE.

That's already achieved: you can run Linux perfectly well using WSL or Parallels. And you don't need any firmware for that, Windows or macOS handle that for you.

> In my opinion, it’s extremely important for desktop Linux distributions to support as much commonly-available hardware as possible, in order to lower the barriers to adoption.

I think that ship have already sailed. Today you can run Linux on almost any desktop computer, be it Windows, macOS or ChromeOS. In a jail of course, without the ability to directly access hardware. I know a lot of people who use Linux and develop for Linux, but most my friends who are less than about 30 years old are not doing that on bare metal and don't plan to do that on bare metal. It's just not worth it.

Whether this is victory or defeat is an interesting question. And whether people like IanKelling wanted that to be a final outcome or not… I have no idea either.

But it was obvious that this would be the end point. The question was “when”, not “if”.

Debian to vote on its firmware path

Posted Sep 1, 2022 15:46 UTC (Thu) by pizza (subscriber, #46) [Link]

> That's already achieved: you can run Linux perfectly well using WSL or Parallels. And you don't need any firmware for that, Windows or macOS handle that for you.

Heh, when MS released WSL1 I quipped that we finally got to the point where "the year of Linux on the desktop" became reality. Unfortunately, it was "Linux on the Microsoft desktop".

> Whether this is victory or defeat is an interesting question. And whether people like IanKelling wanted that to be a final outcome or not… I have no idea either.

I don't think that's the outcome they intended, but I'm forced to agree that it was the inevitable outcome.

But hey, Debian-on-WSL can avoid distributing any proprietary software, so... success!

Debian to vote on its firmware path

Posted Sep 2, 2022 5:08 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (9 responses)

You can't run graphical applications this way.

Also you can't swap ctrl and caps lock.

There is a tool to swap them on windows, but when the tool is in use I can no longer type "@".

WSL is a toy.

Debian to vote on its firmware path

Posted Sep 2, 2022 7:14 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

> You can't run graphical applications this way.

Yes, you can.

> Also you can't swap ctrl and caps lock.

Sure, but why is that a problem?

> WSL is a toy.

Continue to pat yourself on the back. This wouldn't change anything.

Most users want working WiFi and sound much more then they want the ability to swap Ctrl and CapsLock.

Debian to vote on its firmware path

Posted Sep 4, 2022 7:33 UTC (Sun) by LtWorf (subscriber, #124958) [Link] (3 responses)

> Yes, you can.

X11 forwarding has existed since forever. But many extension won't run this way.

> Sure, but why is that a problem?

Try it, the joint of your pinky will thank you. Ergonomicity seems like it should be important for such a supposedly perfect for users solution.

> Most users want working WiFi and sound

Both work fine on linux

> much more then they want the ability to swap Ctrl and CapsLock.

You can just use linux and have both sound AND ergonomic input method. The swap thing is done in system settings on plasma, nothing magic.

Debian to vote on its firmware path

Posted Sep 4, 2022 11:22 UTC (Sun) by khim (subscriber, #9252) [Link] (2 responses)

> Ergonomicity seems like it should be important for such a supposedly perfect for users solution.

Yes, but no. That's something which existing GNU/Linux often can not understand.

The majority of people are not looking for a ways to tune stuff they use. They just need to solve task which they need or want to solve.

If their keyboard comes with Control below Shift then that's what they would use. Period.

> Both work fine on linux.

Nope. That's why we have an article we are discussing. Layman is not taught to look on forums to find solution. S/he is taught to click “Install”, “Ok”, “Agree” and that's it. That's why one of the biggest changes in [rustup] 1.25.0 is the new offer on Windows installs to auto-install the Visual Studio 2022 compilers.

Before newbie would be ready to read forums and fight for working sound, wifi or CapsLock-an-Control s/he would try all simple options. And if WSL gives working WiFi in 5 minutes while native Linux installation takes days… WSL would be used. And that's it.

> You can just use linux and have both sound AND ergonomic input method.

Yes. But the majority of users would never know that. Because for them Linux is that strange thing in a black box which they can use when they open WSL.

Once they have solved their immediate problems (the ability to develop and deploy server software or the ability to finish coursework in college) they may try to play with other settings, but they wouldn't go back to try to install Linux again. Why should they? How would they ever know it may bring them more than WSL?

> X11 forwarding has existed since forever. But many extension won't run this way.

It's not X11 forwarding. Wayland works, too. But if you want you can continue to pat yourself on the back, it's your choice, ultimately.

Just don't expect that others would help you. They would grow up with WSL and that's the only kind of Linux they would know and support.

Debian to vote on its firmware path

Posted Sep 5, 2022 17:23 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (1 responses)

> Yes, but no. That's something which existing GNU/Linux often can not understand.

GNU/Linux is a collection of software. It is expected that software does not understand. Same goes for rocks and buckets of water. Why are we discussing this?

> The majority of people are not looking for a ways to tune stuff they use. They just need to solve task which they need or want to solve.

Do you think the only people purchasing hergonomic hardware are GNU/Linux users? Why would that be? Do you have a source? Empirically, GNU/Linux users do not look any different than other people, so I guess anyone spending enough time on a device or having some health issues might want some ergonomics. The shape of the human body is not correlated to the kernel of the computer.

If you have any academic source that goes against this intuitive idea, I'd be very interested in reading it.

> If their keyboard comes with Control below Shift then that's what they would use. Period.

There is a whole market online for keyboard stickers for people who do not use the layout that is printed on their keyboard. Also people travel and might not want to use the local layout. People can travel regardless of the kernel they mostly use.

> That's why one of the biggest changes in [rustup] 1.25.0 is the new offer on Windows installs to auto-install the Visual Studio 2022 compilers.

Installing anything on windows is certainly not easier than on any distribution. Unless you claim that selecting a software and clicking install is somehow harder than finding a setup online and then click your way trough (avoiding browser bars and whatnot), then having it spawn sub-setups to install c++ redist and so on.

> And if WSL gives working WiFi in 5 minutes while native Linux installation takes days… WSL would be used. And that's it.

Any linux installation takes much less time than installing windows. Have you ever installed windows? It takes several hours against a few minutes for a linux install. And when you're done you must figure out the magic shell commands to enable WSL.

> Yes. But the majority of users would never know that. Because for them Linux is that strange thing in a black box which they can use when they open WSL.

Do you have any data to back this claim?

I understand it is like this for you. But people other than yourself might not be identical clones.

> Once they have solved their immediate problems (the ability to develop and deploy server software or the ability to finish coursework in college)

Problem is that testing software in a VM doesn't mean the software will work when deployed. For example there is an interesting issue at the moment in ubuntu jammy that makes git crash when it runs in some VM.

> Why should they? How would they ever know it may bring them more than WSL?

I could ask you the same question. Why use windows if you are trying to use linux? Then you have 2 systems that break and need fixing instead of just 1. Seems a thing that professionals can't afford.

> It's not X11 forwarding. Wayland works, too.

Wayland isn't production ready.

> But if you want you can continue to pat yourself on the back

This comment is getting repetitive. Moreover in this context it is misused.

> Just don't expect that others would help you. They would grow up with WSL and that's the only kind of Linux they would know and support.

If everybody was using windows, what would even be the point of WSL? People could just do native software. Why make slow software for a vm that runs inside windows instead of just targeting windows, since according to you nobody targets anything else?

WSL exists precisely because windows is no longer the only important platform.

Now you can pat yourself on the back a bit :)

Debian to vote on its firmware path

Posted Sep 5, 2022 18:17 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

> Any linux installation takes much less time than installing windows. Have you ever installed windows?

Why would someone who wants WSL install windows? Their computer probably came with it pre-installed.

Debian to vote on its firmware path

Posted Sep 2, 2022 14:42 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

> WSL is a toy.

Reading this, I'm reminded of the saying "First they ignore you. Then they laugh at you. Then they fight you. Then you win."

I haven't seen any systematic numbers, but given what I've seen anecdotally, there are _significantly_ more WSL deployments than bare-metal desktop linux deployments. An order of magnitude more.

Debian to vote on its firmware path

Posted Sep 2, 2022 14:55 UTC (Fri) by amacater (subscriber, #790) [Link] (1 responses)

It depends very much on who you are/where you are. If you have a corporate/enterprise laptop in a managed setting, then Linux in WSL is, maybe, a compromise acceptable to your IT security folk - "It's only a VM, it's isolated, manageable, sits on Microsoft code - and NOTHING in the OS build is changed".

As suggested, that's a good scenario for deploying any Linux you want with no extra firmware - it's all hand-waved away into VM config and sitting on top of an OS with a pile of drivers.

If you want full graphics, you'll likely need Windows 11 and Microsoft's own Linux running somewhere as a graphics shim. The WSL build for Debian is very similar indeed to the minimal cloud images built for Docker or whatever by the Debian cloud team - akin to a VPS where you don't have absolute full control but can still install Debian packages and know they'll work.

Debian to vote on its firmware path

Posted Sep 2, 2022 16:40 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> and NOTHING in the OS build is changed".

FWIW, the Hyper-V requirement for WSL2 isn't a "no change" to the configuration of the machine. (FWIW, Docker for Windows similarly requires Hyper-V to be used.)

Debian to vote on its firmware path

Posted Sep 6, 2022 8:34 UTC (Tue) by geert (subscriber, #98403) [Link]

Based on my anecdotical evidence, there are more WINE and MONO deployments than bare-metal Windows deployments ;-)

Debian to vote on its firmware path

Posted Sep 1, 2022 1:39 UTC (Thu) by pabs (subscriber, #43278) [Link] (2 responses)

FYI the camera firmware you mention is moving to the CPU but staying non-free:

https://lwn.net/Articles/904776/

Debian to vote on its firmware path

Posted Sep 1, 2022 11:39 UTC (Thu) by excors (subscriber, #95769) [Link] (1 responses)

I don't think it's "moving" to the CPU - it's doing more processing on the CPU in addition to all the work it's doing in firmware. IPU6 still has a 450KB firmware blob (https://github.com/intel/ipu6-camera-bins/tree/main/ipu6/...), which I presume is running on some custom processor(s). An older IPU had a VLIW processor with 512-bit SIMD (https://repository.tudelft.nl/islandora/object/uuid%3A1fe...) that used the "HiveCC" compiler (presumably from Silicon Hive, which Intel bought in 2011), and a more recent one also had "3 scalar processors" (https://www.intel.com/content/dam/www/public/us/en/docume...), and I don't see any indication that IPU6 is radically different.

(I suspect it would be impractical to implement a camera without some firmware running outside the main CPU, because you really need an RTOS - modern imaging features like HDR often require you to reconfigure the sensor and processing pipeline on a per-frame basis with quite strict timing requirements, so you're not going to drive it directly from the Linux kernel.)

Debian to vote on its firmware path

Posted Sep 3, 2022 4:04 UTC (Sat) by pabs (subscriber, #43278) [Link]

Hmm, OK. The article certainly made it sound like some processing that was formerly being done in the camera will now be being done on the CPU. Probably I should have said "part of" :)

Debian to vote on its firmware path

Posted Aug 31, 2022 23:29 UTC (Wed) by moxfyre (guest, #13847) [Link] (2 responses)

> Why must we gatekeep most people from using debian because they bought the wrong machine (I am sceptical of the claims that there is such a thing as a right machine)? Is it really so important to make most newcomers unable to install debian? What does this achieve?

Fully agree.

Most people who are trying to start using Debian GNU/Linux (or another free OS) DID NOT KNOW that they needed specific hardware to start using it.

I've convinced dozens of friends and acquaintances to try out various Linux distros over the years. Many of them did it, many of them liked it, and some of them even stuck with it and became committed FLOSS proponents.

Why would we want to frustrate noobs who are interested in trying out Debian, and punish/belittle/confuse/frustrate them for the fact that the “computer they already have” may require non-free firmware blobs?

Debian to vote on its firmware path

Posted Sep 13, 2022 0:15 UTC (Tue) by ayay (guest, #144420) [Link] (1 responses)

It's not great, but it is what it is.

The nonfree ISO may be a little out of of the way, but if you're walking your friends through it, you can point it to them.

Ubuntu is there for the folks who want it easy. And Debian is fine with that too!

I fail to comprehend why a distro that is famous for its steadfast stance on things *must* change *right now* all of a sudden.

Many of the things we take for granted today are a direct result of all the "basement dwellers" that were "screaming about software freedom, but wouldn't ever shave their necks". I was young, but I was there, and that corporate drivel was *almost* effective in convincing me that, well, maybe proprietary is where it is at after all. I owe those neckbeards a beer or two, proprietary software is bad, unreliable, annoying, and expensive. Myself, I would rather deal with Debian's hidden non-free ISO any time of the day.

Thanks to these stubborn individuals, here we are. Nowhere near perfection, but the "freedom" aspect certainly materialized to a point where former dinosaurs now try to exploit for their gain.

We don't really care, we want to tinker. But we shall never fold.

Debian to vote on its firmware path

Posted Sep 13, 2022 6:49 UTC (Tue) by LtWorf (subscriber, #124958) [Link]

The thing is that the non-free image that everyone uses already exists.

This is just to make it discoverable by everyone rather than just the insiders.

The thinking is that it is better for people to use debian with non-free firmware rather than use osx or windows. Maybe those people will contribute to freedom, if they are allowed to have a taste of it.

Debian to vote on its firmware path

Posted Sep 13, 2022 0:01 UTC (Tue) by ayay (guest, #144420) [Link]

As someone who very often goes for the nonfree ISO on bare metal, I agree.

Of course, I want things to "just work". But Debian being Debian forces me to pay attention: next time I am out buying hardware, I want it to work without nonfree firmware if feasible. I'll install it to squeeze that extra oomph if needed be, stuff is expensive. I have to, but I don't like it.

I tend to run my gear to the ground. Manufacturers abandon things too early. The community doesn't, provided they can carry on.

Case in point: OpenWRT... I flat out refuse to buy anything OpenWRT does not support, because vendor support for consumer - and even prosumer/business, if you ask me - tends to be trash if you're an individual/small business.

OpenWRT is reliable, saved a *LOT* of my gear from the landfill along the years, and just goes on and on and on. It respects me as an user, and in turn I respect its developers. I trust them to not take this stance just out of spite.

Same goes for Debian.

My ath9k devices from 2014 are rocking solid and show no signs of giving up. That's how it should be, and it's all thanks to OpenWRT. I know D-Link and TP-Link could not care less, even if I paid them to do just that!

The landscape for Debian is different than OpenWRT's (thanks to ath9k I assume?), but they still fight the good fight. It may look like a sucker punch - far from it. It raises awareness. And, as things start to gain steam on that direction, with a bunch of new players looking to disrupt the market, RISC-V on the horizon, and so on, it is the worst time possible to abandon this stubborn, yet absolutely necessary stance.

I'll keep using the nonfree iso when I must, and I hope that, one day, I won't have to. Keep fighting the good fight, Debian.

Two different perspectives

Posted Aug 31, 2022 9:19 UTC (Wed) by chris_se (subscriber, #99706) [Link] (3 responses)

I think there are two different perspectives here: one about what is actually running on the system, the other about distribution.

When it comes to what is actually running on the system, I think in some ways it's quite simple: when looking at widely-available hardware that'll be realistically used by most people, there's not much out there that doesn't require non-free firmware in some form or another. While some hardware may not need the firmware to be loaded at runtime, in those cases firmware is loaded from a (EEP)ROM or similar -- and most of the time that firmware is still non-free. If you run x86 (both Intel and AMD), you may opt to skip microcode updates, but the CPU still comes with an initial microcode that's burned into a ROM, and that's still non-free. I've yet to see a NIC or a GPU that has a completely free firmware that is even remotely comparable to typical (not even high-end) offerings on the market in terms of features and performance. (Regardless of whether the firmware has to be loaded at runtime or not.) In the end nearly everybody is running non-free firmware in one form or another. I think it's pretty clear that apart from select corner cases, distributing non-free firmware that is to be loaded at runtime will not really effect how _much_ non-free firmware is running on any given system, it will only effect _how_ that firmware is loaded onto a specific device.

If someone has a principled objection to running any non-free firmware at all, the list of hardware they can use is extremely short. Much, much, much shorter than the list of hardware that is currently supported by Debian's current installer image that doesn't contain non-free firmware. So in my eyes, if the principled objection to the installer images is to Debian supporting users _running_ non-free firmware officially at all, taking this to the logical conclusion would mean that e.g. the vast majority of NIC drivers should not be part of the official installer image, because technically one could argue that they would fall into the category of 'contrib' (free software that requires non-free software, in that case firmware on the NIC's (EEP)ROM, to run). I haven't seen anybody arguing for that.

The other perspective on this issue is distribution. In that case there is a good argument to be made that it's one thing to know that the software will run alongside non-free firmware, it's another to actually distribute said non-free firmware. Here, a principled argument can be made that Debian should never make non-free software part of their official distribution.

In the end, this boils down to whether people want to strictly adhere to the principle of not distributing non-free software as part of the primary distribution just for the principles sake, or whether they want to provide better hardware support -- both of which are very valid positions.

Two different perspectives

Posted Aug 31, 2022 9:27 UTC (Wed) by pabs (subscriber, #43278) [Link]

On NIC firmware, there is a single (1Gbit) Ethernet NIC that has open firmware (the one for Raptor Computing OpenPOWER systems), and several very old WiFi devices.

https://github.com/meklort/bcm5719-fw
https://github.com/hlandau/ortega/
https://wiki.debian.org/Firmware/Open#Network
https://wiki.debian.org/Firmware/Open#Radio

Two different perspectives

Posted Aug 31, 2022 16:37 UTC (Wed) by mfuzzey (subscriber, #57966) [Link]

Agreed but Debian is still distributing non-free firmware (and non-free software too) as part of the non-free repo.
Sure it isn't considered officially to be "part of Debian" but it is still hosted on Debian's infrastructure.

I think the problem (unless they take the radical and IMHO impractical approach or removing everything non-free from Debian servers) is that the repo model is too coarse and everyone has different criteria for what is acceptable for them.

A better approach could be to have everything in the same repository but with a set of tags free/non-free, main_cpu / firmware, hardware-enablement, graphics, audio, rboot-required etc etc.

The advantage would be that multiple tags could be applied to each package and each user gets to set what they want or don't want.

A bit like tagging photos or music files is a more flexible way of organising than just putting them in a directory hierachy based on some criteria.

Two different perspectives

Posted Sep 1, 2022 1:34 UTC (Thu) by khim (subscriber, #9252) [Link]

> If someone has a principled objection to running any non-free firmware at all, the list of hardware they can use is extremely short.

There exist hardware which can be used without any non-free firmware at all. There are exist hardware which can run modern Linux like Debian. But their intersection is empty!

For one simple fact: I don't know any hardware storage medium which is large enough to even contain Debian image and which is usable without upgradeable non-free firmware. Be it IDE or SATA hard drive, SSD or SD card, CD-ROM (with the CD-ROM reader, of course!) or NAS… all these things include non-free firmware. And in all cases it can be upgraded (manufacturers don't always offer official ways to do that, but data recovery companies know how to do that for most devices and the ones which they couldn't crack have that procedure too, they are just not popular enough to warrant the investigation).

That makes the whole “I don't accept non-free firmware” fight so pharisaical it's not even funny: these people accept firmware which can be easily used to subvert their systems (and was used for that in the past), yet refuse to use firmware which can not do that. Who do they fool? And why?

Debian to vote on its firmware path

Posted Aug 31, 2022 10:51 UTC (Wed) by bluca (subscriber, #118303) [Link] (51 responses)

I really had to bite my tongue/fingers a couple of times in that thread. I seriously find it disconcerting, in 2022, to see this hypocritical mental gymnastic around the "oh but non-free it's not really Debian hence we are 100% free! wink wink".
It might have made some sense to put up that charade in the late 90s/early 00s, when the FSF had some sort of influence in the field - although ironically they never bought it either, and the coveted stamp of approval never came. In 2022 the FSF is a non-entity that hasn't done anything useful or noteworthy in the past 15 years. So why do we keep it up?

It is frankly absurd and I don't understand how anybody can seriously buy it. I am to believe that given it is disabled by default (as is the vast majority of the ~50k packages we have - very few are in the installer images), then this proprietary and closed source component that you can download from debian.org, that is maintained and packaged by Debian Developers using Debian hardware and stored on Debian file servers and Debian git forge (Salsa) and distributed to users running Debian image using Debian's apt package management... is somehow not really part of Debian:
http://ftp.debian.org/debian/pool/non-free/n/nvidia-graph...

All because of the lack of some label that says "official", and a couple of paragraphs of text that says so, "because yes". That makes it non-Debian and hence Debian is 100% free. Really? Does anybody seriously buy any of that?

I certainly don't. Debian includes and ships proprietary drivers and firmwares, as it should because it's necessary to actually function on real hardware that users actually have, as opposed to the ideal hardware with no proprietary component that doesn't exist anywhere, and this GR is a good and long overdue step in the right direction.

Debian to vote on its firmware path

Posted Aug 31, 2022 14:07 UTC (Wed) by pizza (subscriber, #46) [Link] (41 responses)

> It might have made some sense to put up that charade in the late 90s/early 00s, when the FSF had some sort of influence in the field - although ironically they never bought it either, and the coveted stamp of approval never came.

The thing is, even the FSF took the opposite stance. In order to create a fully-Free system, it was necessary to operate/utilize on proprietary platforms, and each replacement component could be incrementally developed.

Making it harder to install/use Free Software on a non-Free platform benefits nobody, least of all the Free Software movement itself!

And, FFS, *every* piece of hardware between the keyboard to the display requires non-free firmware. The core CPU itself, the keyboard & mouse (doubly so if it is wireless), the motherboard (both its BIOS and its embedded controller), all PCIe devices, all SATA/NVMe devices, your sound hardware (fun fact: the original Sound Blaster was built around an i8051 MCU), graphics/display system, webcam, card reader, actual USB sticks and SD cards, any printers, network connectivity (wireless & wired alike) and all attached displays all have embedded processors running completely proprietary firmware. The _only_ difference is where/how that firmware is loaded and how easy it is to replace.

Once you step away from Open-only-by-historical-fluke x86, things get _more_ proprietary. The most popular ARM platforms require proprietary firmware to even _boot_ -- so there's never going to be a "completely free" installer for that stuff.

Logic would dictate that run-time-downloadable firmware would be preferable as that make it easier to eventually replace with truly Free alternatives, instead of having to muck with reverse-engineering the update process (if any) and risking bricking the hardware.

Debian to vote on its firmware path

Posted Aug 31, 2022 15:33 UTC (Wed) by brunowolff (guest, #71160) [Link] (40 responses)

> And, FFS, *every* piece of hardware between the keyboard to the display requires non-free firmware. The core CPU itself, the keyboard & mouse (doubly so if it is wireless), the motherboard (both its BIOS and its embedded controller), all PCIe devices, all SATA/NVMe devices, your sound hardware (fun fact: the original Sound Blaster was built around an i8051 MCU), graphics/display system, webcam, card reader, actual USB sticks and SD cards, any printers, network connectivity (wireless & wired alike) and all attached displays all have embedded processors running completely proprietary firmware. The _only_ difference is where/how that firmware is loaded and how easy it is to replace.

It is possible to buy motherboards where source to the firmware and schematics are available for the whole thing for Power 9. Power 9
is competitive with AMD's and Intel's offering on performance, though there is a significant cost penalty.
Some devices (e.g. mass storage, GPUs not being used to compute, displays) can be limited so that only DOS attacks can be done without physical access.
The power ISA is open and there is an open implementation that runs on FPGAs. It isn't usable for a desktop, but there is a BMC (it is really more than that) that uses it, that you can currently buy. It costs too much for most people at this point. But it might get integrated into future motherboards.
The point is that there are people working to provide real open alternatives to the common proprietary stuff. In order for this stuff to become cost competitive (or even have development continue), people that care about this stuff need to vote with their wallets.

Debian to vote on its firmware path

Posted Aug 31, 2022 19:14 UTC (Wed) by WolfWings (subscriber, #56790) [Link] (6 responses)

I'm sorry but building a competing ISA to x86/ARM to try to gain freedoms is unlikely to ever succeed, because end-users whose wallets you're chasing are either too skint to afford the cost penalty... or have fat enough wallets they're more likely to chase the better performance of the existing x86 ISAs for their personal devices and projects, with use of ARM in IoT-type setups.

Work to open up and free more x86 components and devices helps everyone, but in the meantime the rest of us need systems that simply work, but aren't pissing away money in the name of freedoms that don't actually help us.

Especially in today's legal climate regarding IP rights and the enormously long-tail complex supply chain of contracts for firmware being developed, patents, etc, we have foundational issues to address there before we can make full progress. Even when hardware vendors are open to discussing open-sourcing things it seems it always runs aground on some random shoal of a third-party-of-a-third-party contract buried deep in the chain of where they sourced a co-processor core from.

Debian to vote on its firmware path

Posted Sep 1, 2022 8:27 UTC (Thu) by brunowolff (guest, #71160) [Link] (3 responses)

Power is competitive with x86_64 in some areas already, particularly on the high end. IBM is still putting resources into developing Power so there is an ecosystem there and Linux systems run on Power hardware so there is potential for it to become popular enough to be cost competitive for markets.
There seems to be interest in avoiding high licensing costs of some of embedded devices (ARM). This has made RISC-V a hot area and Linux support is getting started. Using the Power ISA would be another option for this area and would have probably been better if IBM had opened up the ISA sooner.
In the desktop area it will be harder to get traction because currently IOS and Windows only get support for a few ISAs (unlike Linux). But change does happen there, and they could gain support for Power or RISC-V.

Debian to vote on its firmware path

Posted Sep 1, 2022 15:40 UTC (Thu) by pizza (subscriber, #46) [Link]

Don't pin your hopes on RISC-V being any "freer" than Arm or x86 or whatever.

If anything, its looser licensing terms mean for a lot more fragmentation and variation in its implementations, even when compared to the utter mess that Arm used to be. And that's just the core bits -- the various implemeted SoCs are just as much of a proprietary/binary blob IP minefield as parts that use different CPU cores.

Debian to vote on its firmware path

Posted Sep 2, 2022 0:14 UTC (Fri) by pabs (subscriber, #43278) [Link]

IIRC POWER10 puts a non-free blob on a chip in the path between CPU and RAM, that can do anything to the requests or responses, so it is a step down in freedom compared to POWER9 unfortunately.

Debian to vote on its firmware path

Posted Sep 3, 2022 9:07 UTC (Sat) by joib (subscriber, #8541) [Link]

I don't work in the embedded industry, but from what I've seen from afar there is zero momentum around Power after IBM opened the ISA. OTOH there seems to be a lot happening around RISC-V. Which is a bit weird considering the software ecosystem around Power is much more mature. But maybe people are afraid the IBM behemoth will turn around and screw them over, and thus RISC-V is a safer bet?

So I don't see much future for Power. Sure, IBM will keep making their high end Power CPU's as long as enough of their captive customers buy them, but it seems the long-term trend is Power retreating ever further into the high end corner, with x86 eating more and more of the server market.

I applaud the work Raptor is doing and wish them luck, but it's a pretty expensive niche product for a very niche audience. It's very far from what would be needed for any kind of revival of the Power ecosystem.

And to be sure, RISC-V growing upwards into servers, end user laptops and other devices is far from certain and will in any case take a long time, but still it seems a much less risky bet than betting on Power reversing its fortunes.

(And no, as mentioned, RISC-V being a free ISA doesn't imply RISC-V devices being free from proprietary firmware.)

Debian to vote on its firmware path

Posted Sep 1, 2022 9:46 UTC (Thu) by paulj (subscriber, #341) [Link] (1 responses)

Some of the 'people' with the largest wallets in the tech-buying industry care /very/ much about proprietary firmware. To the extent they have developer teams working on replacing firmware with open versions. Either by working with (and putting pressure on) vendors, or - in some cases - developing their own hardware with their own firmware - which (if the project succeeds) sometimes gets open-sourced.

They're doing this not for ideological reasons, but because of the security implications of proprietary firmware.

Debian to vote on its firmware path

Posted Sep 1, 2022 9:48 UTC (Thu) by paulj (subscriber, #341) [Link]

One example of this would be the work certain large tech companies are doing on Coreboot and related early-boot software.

Debian to vote on its firmware path

Posted Aug 31, 2022 20:24 UTC (Wed) by IanKelling (subscriber, #89418) [Link] (2 responses)

> And, FFS, *every* piece of hardware between the keyboard to the display requires non-free firmware.

That is far from true for keyboards. I'm typing on a keyboard with 100% free firmware, as I have been for several years now. There has been an explosion of free keyboard firmware in the last few years. The brand I use is Keyboardio. All their keyboards have free firmware. Other than than their website not meeting the FSF respects your freedom standards, for example nonfree javascript, I recommend their keyboards.

Debian to vote on its firmware path

Posted Sep 4, 2022 23:33 UTC (Sun) by intelfx (subscriber, #130118) [Link] (1 responses)

> That is far from true for keyboards. I'm typing on a keyboard with 100% free firmware

What you have is a ridiculously rare exception.

Debian to vote on its firmware path

Posted Sep 5, 2022 10:14 UTC (Mon) by atnot (guest, #124910) [Link]

I doubt it's even true at that, most microcontrollers used in OSHW designs have proprietary bootloaders, at minimum in mask ROM.

Debian to vote on its firmware path

Posted Sep 1, 2022 1:44 UTC (Thu) by khim (subscriber, #9252) [Link] (29 responses)

> In order for this stuff to become cost competitive

This would never work. Economics of scale is real thing and hardware developed for tiny group of freedom-lovers would always be more expensive than something mass-produced.

Even FSF-endorsed devices come with nonfree firmware in their storage components. To pretend that they are using fully-free hardware they have to look the other way, handwave and say that it's not big deal because that this thing only simply keeps all the data which you use, how can it be more dangerous than firmware for your sound card?

Debian to vote on its firmware path

Posted Sep 1, 2022 2:08 UTC (Thu) by rodgerd (guest, #58896) [Link]

They do worse than that - they lie about the security and privacy risks of using as-shipped blobs in devices and refusing to allow them to be updated to fix problems.

Debian to vote on its firmware path

Posted Sep 1, 2022 8:48 UTC (Thu) by brunowolff (guest, #71160) [Link] (27 responses)

Mass storage can be considered a black box from a freedom perspective in that they support an API and you don't effectively program them so that the internal implementation does impact your freedom. Though there might be cases where you would want to fix bugs in the implementation without the permission or support of the manufacturer, so there are reasons one might want access to that source code.
From a security and owner control perspective, you can mitigate hostile mass storage devices by encrypting data on the cpu before storing it on the device. This is pretty common these days in order to protect data at rest. This limits attacks on the stored data to denial of service. The devices are also well positioned to do side channel attacks, but without access to a network the attacker is going to need to get physically close to retrieve the data or the device is going to need a built in radio and try to keep that secret. This makes mass surveillance attacks hard. If you are worried about being targeted specifically by very well resourced organizations, then your problem is going to be much larger in scope, because you might not even be running (just) the hardware you think you are.

Debian to vote on its firmware path

Posted Sep 1, 2022 9:59 UTC (Thu) by bluca (subscriber, #118303) [Link] (2 responses)

That's just mental gymnastic to bury the head in the sand. The reality is that almost all commercially available hardware has proprietary firmwares all over the place, some of which are updatable (which is good, allows easier reverse engineering to potentially have open alternatives and security updates). You don't program the keyboard or GPU or CPU either, they all have ""APIs"". It's more of the usual sticking fingers in ears and going "lalala can't hear you over my freeness"

Debian to vote on its firmware path

Posted Sep 1, 2022 11:23 UTC (Thu) by brunowolff (guest, #71160) [Link] (1 responses)

I disagree. The context of what you are trying to do makes a big difference. Firmware in mass storage generally isn't going to limit what you want to do if you pass it encrypted data. If the data is not encrypted then there is the possibility of the hardware not letting you work with certain kinds of data. For example there could be checks preventing storage of data matching particular hashes. In keyboards and mice there are potential security issues, and if you are worried about that threat, you are going to want free firmware (or at least firmware that has been reverse engineered enough to tell it isn't doing things you don't want). GPUs are already doing hostile stuff that is enabled by proprietary firmware. In particular there was firmware that intentionally crippled GPUs when they were being used for crypto mining. There are also DRM limitations enforced by a combination of proprietary drivers and firmware. (Limiting the resolution while displaying video is a common one.)
Different people are going to care more about different parts of the system and might find it useful to allow non-free firmware in some parts in order to save money or get better performance, but require free firmware in other parts.
If everyone ignores the issue, things aren't likely to change. To get to a better place people need to preferentially by hardware that uses free firmware, demonstrate that there is a market for devices that use free firmware. One way to do that is to support people who are reverse engineering or developing free firmware for devices that come with proprietary firmware. Such as Raptor's bounty for the BCM5719 which encouraged a couple of people to do a lot of work that has resulted in free firmware for that device. At some point a competitor might decide to provide a chip that comes with free firmware, because they see that there are people that will prefer theirs over Broadcom's.
Personally, I don't find much difference in whether the firmware is upgradeable or not with regard to freedom as long as I'm in control of the upgrades. That control needs to include not being blackmailed into forced firmware upgrades (such as with bluray), allow for me to use my own firmware (without an OEM or manufacturer signature) if somehow I were to get some and should in general allow a way to downgrade as well (in case there is an issue with an upgrade).
The FSF seems to include an objection to cases where lack of knowledge creates an unfairness with being able to update firmware (as opposed to limitations based on signatures) and I don't think that circumstance is something they should be taking a hard line against.

Debian to vote on its firmware path

Posted Sep 1, 2022 15:39 UTC (Thu) by khim (subscriber, #9252) [Link]

> Firmware in mass storage generally isn't going to limit what you want to do if you pass it encrypted data.

And firmware in a WiFi card or sound card would? With a firmware provided to Debian via official channels? Really? We know people planted backdoors into firmware of storage. Can you show me something similar about firmware delivered via official OS distributor?

> In particular there was firmware that intentionally crippled GPUs when they were being used for crypto mining.

How is that “hostile”? Any layman would say it's a good thing. Because it means such GPU would be cheaper and would still be perfectly usable to play games.

> There are also DRM limitations enforced by a combination of proprietary drivers and firmware. (Limiting the resolution while displaying video is a common one.)

Show me how I can watch Netflix in full resolution with free firmware. Then you would have a case.

And I don't know of any DRM software which may forbid me to watch high-resolution video which have no protection.

> To get to a better place people need to preferentially by hardware that uses free firmware, demonstrate that there is a market for devices that use free firmware.

That market would always provide slow, inefficient and/or expensive devices. Usually all three at the same time. Simply because you can not have you cake and eat it, too: if you demand the ability to tinker with firmware you have to pay.

There is nothing wrong with that desire, but please stop trying to make others pay for your desires.

I don't want an iPhone because I don't like the level of control Apple imposes on iPhone owners. But I don't try to, somehow, cripple the code I write to make it impossible to use on iPhones. That would be stupid and wrong. If people like to be left out without online banking when their country does something uncle Sam does't like… who am I to lecture them? Who gave me that right?

> One way to do that is to support people who are reverse engineering or developing free firmware for devices that come with proprietary firmware.

Sure. And easy way to help such people is to make sure firmware is not stored in the bowels of the hardware, but can be effectively loaded from OS distribution media. That's what people like Richard Hughes enable. FSF does the exact opposite: instead of making it easier to make firmware free it makes it hard to touch it in the first place.

> Personally, I don't find much difference in whether the firmware is upgradeable or not with regard to freedom as long as I'm in control of the upgrades.

FSF have different rules. Accordring to FSF it's absolutely fine to have password-stealing firmware in your keyboard, spyware in your web cam and computer-hijacking malware in bowels of your SSD — as long as you don't make it possible to study it that POS it, somehow respects your freedom. How the hell that stance is useful for anyone?

Debian to vote on its firmware path

Posted Sep 1, 2022 10:59 UTC (Thu) by khim (subscriber, #9252) [Link] (23 responses)

> Mass storage can be considered a black box from a freedom perspective in that they support an API and you don't effectively program them so that the internal implementation does impact your freedom.

The same can be said about Windows in case when you use it to run Linux in WSL.

> From a security and owner control perspective, you can mitigate hostile mass storage devices by encrypting data on the cpu before storing it on the device.

But then you have to trust that your CPU does what it says it does. Including SMM mode. There are always code which executes before your beloved free software has a chance to do something with CPU and it comes from storage controlled by updatable firmware.

> This makes mass surveillance attacks hard.

Hard for whom? Maker of the hardware? Don't make me laugh. Modern hardware is so complex that maker of such hardware can embed significant part of library of congress and nobody would ever notice.

> If you are worried about being targeted specifically by very well resourced organizations, then your problem is going to be much larger in scope, because you might not even be running (just) the hardware you think you are.

Yet — and giving you tampered hardware would be easier that attacking you via firmware which comes from official source and is distributed via thousands of Linux distributions.

I'm not saying such attacks are impossible. But before it becomes feasible you have to make sure all other venues of attack are closed.

Today FSFs stance sounds crazy: it debates whether you need to replace a steel door with a door made from adamantium in a house where walls are made from paper.

Debian to vote on its firmware path

Posted Sep 1, 2022 11:47 UTC (Thu) by brunowolff (guest, #71160) [Link] (22 responses)

>> Mass storage can be considered a black box from a freedom perspective in that they support an API and you don't effectively program them so that the internal implementation does impact your freedom.

> The same can be said about Windows in case when you use it to run Linux in WSL.

Sorry, in my opinion running anything on a recent version of Windows is insane (at least the versions available to consumers).

>> From a security and owner control perspective, you can mitigate hostile mass storage devices by encrypting data on the cpu before storing it on the device.

> But then you have to trust that your CPU does what it says it does. Including SMM mode. There are always code which executes before your beloved free software has a chance to do something with CPU and it comes from storage controlled by updatable firmware.

That's why I bought a Blackbird. I agree that you don't want to use modern AMD, Intel or ARM CPUs if you can avoid them. The initial code can come from ROMs (or updatable variants) and code from mass storage before encryption support is available can still be checked using hashes.

>> This makes mass surveillance attacks hard.

> Hard for whom? Maker of the hardware? Don't make me laugh. Modern hardware is so complex that maker of such hardware can embed significant part of library of congress and nobody would ever notice.

You don't think that national security agencies don't talk to hardware and software companies about making changes to make the agencies jobs easier?

>> If you are worried about being targeted specifically by very well resourced organizations, then your problem is going to be much larger in scope, because you might not even be running (just) the hardware you think you are.

> Yet — and giving you tampered hardware would be easier that attacking you via firmware which comes from official source and is distributed via thousands of Linux distributions.

That's what I implied. In this case hostile firmware is a minor issue compared to other attack avenues.

> I'm not saying such attacks are impossible. But before it becomes feasible you have to make sure all other venues of attack are closed.

> Today FSFs stance sounds crazy: it debates whether you need to replace a steel door with a door made from adamantium in a house where walls are made from paper.

I don't think that security is a major part of FSF's stance. However, I think people who care about security have common interest with the FSF in avoiding hardware with proprietary firmware. The two groups are going to have different opinions on the tradeoffs and mitigations when dealing with proprietary firmware, though.

I think that the FSF should modify their stance on updatable firmware slightly. In my opinion unfairness derived from the end users' lack of knowledge about the firmware, should not trigger a hard line against firmware upgrades. Though in current practice there are other kinds of unfairness in much of the updatable firmware used now, and the change in stance wouldn't necessarily change much right at this time.

Debian to vote on its firmware path

Posted Sep 1, 2022 16:16 UTC (Thu) by khim (subscriber, #9252) [Link] (21 responses)

> Sorry, in my opinion running anything on a recent version of Windows is insane (at least the versions available to consumers).

If you run Windows software… maybe. Here we are talking about using Windows as WSL-backbox for Linux. Was there ever any evidence that it doesn't work according to specs? Not because of bugs (bugs happen with real hardware, too, even without any firmware), but on purpose?

> The initial code can come from ROMs (or updatable variants) and code from mass storage before encryption support is available can still be checked using hashes.

Is it a joke or stupidity? ROM on these old platforms would happily loads any random crap from the first sector of storage and then execute that. There are no checksums. And we are talking about firmware here. It can easily stop presenting malware content to the host system after initial bootup. You may try to attach that device to computer as non-bootable device, but this wouldn't save you since firmware is not obliged to provide you with hostile payload unconditionally in that case.

And since firmware is not available for scrutiny but can be different on different HDDs or SSDs you can not even rely on work of others for your safety (like you can in cases where firmware is included in Debian or any other OS and thus is available for dissemination of security information).

> You don't think that national security agencies don't talk to hardware and software companies about making changes to make the agencies jobs easier?

I don't know if they talk or not. But even if they do they would, naturally, do what is easier for them and would alter storage system firmware on select few devices. In fact we know they did that.

What they wouldn't do is to pass “firmware with surprise” via official channels where it exposes these “surprises” to millions of people and thousands of security researchers. That's just crazy thing for them to do and we have no evidence they ever have done that.

> However, I think people who care about security have common interest with the FSF in avoiding hardware with proprietary firmware.

Except you couldn't. Not if you want to use modern hardware. If you are really paranoid you may buy obsolete or exotic hardware which can be used without proprietary firmware, but it's stupid to make general-purpose distribution which you can only use on some rare and expensive hardware.

I think WSL (and other virtual machines) actually justify existence of firmware-free version (because you don't need firmware if you are running on virtual machine), but that shouldn't be the default version you give to newbies.

> I think that the FSF should modify their stance on updatable firmware slightly.

I don't know about upgradable firmware, but I think they should reverse their stance on “transient firmware” which is loaded from host system before you can use the device.

Today it's regarded as awful, crazy, don't touch, don't tell kind of software while umodifyable firmware is treated like a gold standard. In reality these things should be reversed: umodifyable firmware means you would never be able to update it. The notorius printer driver embedded in umodifyable firmware would forever be broken. Even if someone would develop free firmware it would still be broken.

On the other hard firmware which is loaded on each boot from host system can never be worse than umodifyable firmware: if it's signed and you couldn't alter it — for all intents and purposes it's now works as hardware, if you can alter it — you can try to develop free version.

Debian to vote on its firmware path

Posted Sep 1, 2022 17:06 UTC (Thu) by brunowolff (guest, #71160) [Link] (20 responses)

>> Sorry, in my opinion running anything on a recent version of Windows is insane (at least the versions available to consumers).

> If you run Windows software… maybe. Here we are talking about using Windows as WSL-backbox for Linux. Was there ever any evidence that it doesn't work according to specs? Not because of bugs (bugs happen with real hardware, too, even without any firmware), but on purpose?

I was talking about the OS itself, not the applications. Telemetry is a privacy nightmare. You don't get to control updates.

Also going back to the API discussion, the risk of using WSL is a lot different than using say a mass storage device you don't full trust. Mass storage devices don't have an easy way to communicate data back to an opponent. WSL is going to be in regular communication with Microsoft and if you don't trust it, that makes it a much bigger deal.

>> The initial code can come from ROMs (or updatable variants) and code from mass storage before encryption support is available can still be checked using hashes.

> Is it a joke or stupidity? ROM on these old platforms would happily loads any random crap from the first sector of storage and then execute that. There are no checksums. And we are talking about firmware here. It can easily stop presenting malware content to the host system after initial bootup. You may try to attach that device to computer as non-bootable device, but this wouldn't save you since firmware is not obliged to provide you with hostile payload unconditionally in that case.

I wasn't talking about old systems. I was talking about trying to design a current system that could boot up without having to trust firmware on a mass storage device fully. (You can't prevent denial of service attacks.)
ROM doesn't load anything. The code on the ROM is going to load stuff, but it is under your control how that is done. It is a place to store code that you don't want firmware to mess with.

I suspect you are mixing this up with the argument others are having about non-free firmware being better fixed in ROM rather than being upgradable. That is not what I was talking about here.

>And since firmware is not available for scrutiny but can be different on different HDDs or SSDs you can not even rely on work of others for your safety (like you can in cases where firmware is included in Debian or any other OS and thus is available for dissemination of security information).

Sure you can. The device can be set up so that you give it encrypted blobs and it returns the encrypted blobs later or nothing or garbage blobs which can easily be detected. This limits the device to denial of service attacks and some side channel attacks that will be low bandwidth and/or require the attacker to have resources physically present nearby.

>> You don't think that national security agencies don't talk to hardware and software companies about making changes to make the agencies jobs easier?

> I don't know if they talk or not. But even if they do they would, naturally, do what is easier for them and would alter storage system firmware on select few devices. In fact we know they did that.

> What they wouldn't do is to pass “firmware with surprise” via official channels where it exposes these “surprises” to millions of people and thousands of security researchers. That's just crazy thing for them to do and we have no evidence they ever have done that.

Well it was pretty widely reported the FBI talked to Microsoft about making sure bitlocker didn't cause them problems. They do care about compromising systems at scale. The NSA also cares about this and have compromised NIST standards in the past.

>> However, I think people who care about security have common interest with the FSF in avoiding hardware with proprietary firmware.

> Except you couldn't. Not if you want to use modern hardware. If you are really paranoid you may buy obsolete or exotic hardware which can be used without proprietary firmware, but it's stupid to make general-purpose distribution which you can only use on some rare and expensive hardware.

You are wrong. It is possible to buy modern hardware now that uses free firmware. You can't build a complete system yet, but you can do things to mitigate what the non-free firmware can do. If people want more hardware covered and/or better pricing in the future, they need vote with their wallets.

> I think WSL (and other virtual machines) actually justify existence of firmware-free version (because you don't need firmware if you are running on virtual machine), but that shouldn't be the default version you give to newbies.

Except that WSL is a bigger threat than most non-free firmware.

>> I think that the FSF should modify their stance on updatable firmware slightly.

> I don't know about upgradable firmware, but I think they should reverse their stance on “transient firmware” which is loaded from host system before you can use the device.

I agree that some change is in order, but not to the extent you do.

> Today it's regarded as awful, crazy, don't touch, don't tell kind of software while umodifyable firmware is treated like a gold standard. In reality these things should be reversed: umodifyable firmware means you would never be able to update it. The notorius printer driver embedded in umodifyable firmware would forever be broken. Even if someone would develop free firmware it would still be broken.

> On the other hard firmware which is loaded on each boot from host system can never be worse than umodifyable firmware: if it's signed and you couldn't alter it — for all intents and purposes it's now works as hardware, if you can alter it — you can try to develop free version.

It is possible for it to be worse. It allows for provider of the firmware to change it. If they have leverage over you (e.g. bluray where access to new discs can be restricted), then it is possible make you choose between suffering from the leverage or suffering from an intentional regression in the new firmware. This couldn't be done if the firmware was fixed in the hardware. It also allows for some other attack modes on your systems, but that isn't normally going to be a big deal. For much hardware, the leverage issue isn't going to be a significant risk, so it probably should be treated similarly. While there is an unfairness that only some people can generate updates (at least easily) in many cases this is no worse than no updates.

Debian to vote on its firmware path

Posted Sep 1, 2022 18:18 UTC (Thu) by khim (subscriber, #9252) [Link] (17 responses)

> This couldn't be done if the firmware was fixed in the hardware.

Of course it could be done! Not only it could be done, it's actually done rountinely right now, today! Wake up! This or this are just tip of the iceberg!

Companies regularly sell silicone where certain features can be disabled and enabled. Market diversification, you see. And they don't need upgradeable firmware for that. Upgradeable firmware just makes it a bit more convenient.

> Except that WSL is a bigger threat than most non-free firmware.

Then why are we pushing people in that direction? Most newbies, the people who care about default choices Debian makes most are not in position of picking hardware.

They already have a hardware. They can only pick what to install on it. And if Debian on bare metal doesn't work while WSL works… they would go with WSL.

> If people want more hardware covered and/or better pricing in the future, they need vote with their wallets.

If they want to vote with their wallets they would do that. But you are trying to force everyone to pick that vote even if they are not even thinking about firmware or hardware.

They just need Linux to do their corsework in college. I've asked my friend who is studying in college to ask about what they did. 9 our 10 picked WSL. The remaining 1 couldn't use WSL, but they don't need to because macOS is close enough to Linux for their course.

Is that what FSF wanted? IDK, but that was inevitable thus I would assume the answer is “yes”.

> The device can be set up so that you give it encrypted blobs and it returns the encrypted blobs later or nothing or garbage blobs which can easily be detected.

Who would give it encrypted blobs? OS? Where would that OS come from?

> I was talking about trying to design a current system that could boot up without having to trust firmware on a mass storage device fully.

And I'm talking about devices that FSF actually recommends. Old crippled ThinkPads with no boot verification, mostly.

> It is a place to store code that you don't want firmware to mess with.

But firmware does control the space where your code lives! That's precisely my point!

If you want to ensure that your CPU wouldn't be under control of NSA then you first need to design something which doesn't depend on binary blobs to, you know, access the RAM.

Debian to vote on its firmware path

Posted Sep 1, 2022 18:59 UTC (Thu) by brunowolff (guest, #71160) [Link] (4 responses)

>> This couldn't be done if the firmware was fixed in the hardware.

> Of course it could be done! Not only it could be done, it's actually done rountinely right now, today! Wake up! This or this are just tip of the iceberg!

No it isn't. Sure you can sell people crippled chips for a discount, but without a way to update them you don't have a way to leverage them to update firmware.

>> Except that WSL is a bigger threat than most non-free firmware.
.
> Then why are we pushing people in that direction? Most newbies, the people who care about default choices Debian makes most are not in position of picking hardware.

What we? If anyone asks me I tell them don't use modern windows for anything on the consumer side. Enterprises have some ability to disable some of the crap, but I'm not sure how much.

> They already have a hardware. They can only pick what to install on it. And if Debian on bare metal doesn't work while WSL works… they would go with WSL.

If they already bought hardware, then they have to make do with what they have. But I'd still never tell anyone to use WSL. If their hardware is so bad that that is the only option, I suggest replacing what they need to after they are sure they want to run linux. (Only stuff that won't work, not solely because non-free firmware is needed to make it work.) But you can get most stuff working under Linux, so there shouldn't be much that needs to be replaced even in the worst case.

>> If people want more hardware covered and/or better pricing in the future, they need vote with their wallets.

> If they want to vote with their wallets they would do that. But you are trying to force everyone to pick that vote even if they are not even thinking about firmware or hardware.

How the heck do you come to that conclusion about my actions? I'm encouraging people to support people who are spending money and/or time to make hardware that works without proprietary firmware more available for people that want it. I recommend people avoid non-free firmware where they can, but I don't advocate banning it from existence. Though it might make sense to require source to be escrowed for some consumer devices to make sure support is available if a company goes out of business, in line with right to repair initiatives.

> They just need Linux to do their corsework in college. I've asked my friend who is studying in college to ask about what they did. 9 our 10 picked WSL. The remaining 1 couldn't use WSL, but they don't need to because macOS is close enough to Linux for their course.

A university should not be requiring students to install invasive software on their personal machines (including Linux) whether it is free or not. They should be providing the environment to run that stuff, with remote access available where it makes sense.

> Is that what FSF wanted? IDK, but that was inevitable thus I would assume the answer is “yes”.
>> The device can be set up so that you give it encrypted blobs and it returns the encrypted blobs later or nothing or garbage blobs which can easily be detected.

> Who would give it encrypted blobs? OS? Where would that OS come from?

From the encrypted file system on your mass storage device. I think you misunderstood the context of this part of the discussion as your replies have frequently been nonsensical with the intended context.

>> I was talking about trying to design a current system that could boot up without having to trust firmware on a mass storage device fully.

> And I'm talking about devices that FSF actually recommends. Old crippled ThinkPads with no boot verification, mostly.

Why? That isn't what this thread was about.

>> It is a place to store code that you don't want firmware to mess with.

> But firmware does control the space where your code lives! That's precisely my point!

There are machines where the very early boot firmware is free. I'm not talking about using machines that require an IME, PSP or TrustZone (or whatever ARM calls their crap). In that case you can pull the code needed
for early boot without out accessing a mass storage device to avoid pulling data under control of untrusted firmware until you are at the point where you can verify the authenticity of the data returned by mass storage.

> If you want to ensure that your CPU wouldn't be under control of NSA then you first need to design something which doesn't depend on binary blobs to, you know, access the RAM.

Well that is an interesting topic. Currently there are modern machines where you can do that. Power 9 for example. However there have been some changes in order to provide more powerful memory lately and for Power 10 IBM decide to use proprietary firmware in order to access main memory. This has made Power 10 undesireable for some purposes. There were some impacts on sales and PR because of this decision. And there is speculation that a time crunch might have been partially responsible for the change. Also there is another move to CXL coming. At this point it isn't clear how things are going to go for Power 11. And to some extent that's why wallets matter. The hit on Power 10 sales were probably small relative to IBM's total sales. The more people buying hardware that doesn't need non-free firmware, the more incentive there is to produce such hardware.

Debian to vote on its firmware path

Posted Sep 1, 2022 19:20 UTC (Thu) by pizza (subscriber, #46) [Link]

> A university should not be requiring students to install invasive software on their personal machines (including Linux) whether it is free or not. They should be providing the environment to run that stuff, with remote access available where it makes sense.

There's a massive chasm between this "should" and the real world of what most students are forced to accept. And yes, it is _forced_ because the alternative is to fail the course and possibly even the program.

We can lobby all we want to improve the baseline for the future, but we still have to work with (and within) what we have _today_.

Debian to vote on its firmware path

Posted Sep 1, 2022 19:27 UTC (Thu) by pizza (subscriber, #46) [Link] (2 responses)

> and to some extent that's why wallets matter. The hit on Power 10 sales were probably small relative to IBM's total sales. The more people buying hardware that doesn't need non-free firmware, the more incentive there is to produce such hardware.

What I strongly suspect is that it's not "Free" firmware that these organizations need, in of itself -- instead, they need a way to attest/confirm that said firmware has not been modified from what the manufacturer intended to ship. Sufficiently powerful organizations can also force the manufacturer to supply the complete source code so it can be validated independently. The point here is to validate and trust their supply chain. "Free" firmware is (part of) one potential path to that goal, but hardly the only one.

Debian to vote on its firmware path

Posted Sep 1, 2022 19:34 UTC (Thu) by brunowolff (guest, #71160) [Link]

Yeah, probably some people buy a cheap machine to put the crap on and others who can't afford that have to try to manage putting the crap on a machine they use for other stuff and try to manage the risks of doing that. But people should try to make noise when they are forced to do that.

Debian to vote on its firmware path

Posted Sep 1, 2022 19:42 UTC (Thu) by brunowolff (guest, #71160) [Link]

Note the above comment replied to the wrong comment.
For the current thread, I don't think just having powerful organizations get access to the source is good enough. Other people want to be able to make changes to firmware without have to beg the manufacturer for permission to make a change. This might be for research, bug fixes, adding or removing functionality.

Debian to vote on its firmware path

Posted Sep 6, 2022 10:59 UTC (Tue) by ras (subscriber, #33059) [Link] (11 responses)

> If you want to ensure that your CPU wouldn't be under control of NSA then you first need to design something which doesn't depend on binary blobs to, you know, access the RAM.

Accessing the RAM securely isn't an insurmountable problem. To wit: AMD-SEV. Used in the right way your VM is then secure from the host OS. Or at least I think so - I haven't looked closely enough to be 100% positive. Currently my mental model of what it does is if you have a host running on AMD-SEV in Russia, the NSA should be able to able to run a VM this totally Russian controlled OS safely (bugs, side channels, and god knows what else notwithstanding). It works because the NSA should be able to secure a rock solid trust relationship with TPM in the AMD CPU that bypasses the host. All the host sees is an encrypted blob of data, and presumably secure network comms flowing in and out.

So no, even if you are swimming in an ocean of non-free firmware you don't trust, in principle it doesn't have to be allowed access and total control of the space you live in. I'll grant you it does right now. But that's at loggerheads with security concerns. Just as I can't see NSA or the military being happy with WiFi controller with DMA access to RAM and getting it's firmware from China, I imagine China feels the same way about Windows. So there are forces pushing towards isolation of the components. Whether it happens is an interesting question, but a commoditized WiFi controller you don't have to trust even though it receives non-free firmware updates is probably attractive to the people AMD-SEV is being sold to.

Debian to vote on its firmware path

Posted Sep 6, 2022 11:43 UTC (Tue) by khim (subscriber, #9252) [Link]

I don't think you understand what I wrote. Please read again.

The problem is not that you can not trust memory. The problem is that to even access that memory in a modern system you have to execute a binary blob (large one, megabytes-sized!) on the host cpu!

I don't fear for NSA. If they control AMD, IBM, Intel… they probably can safely run that OS in Russia.

But would Russians be able to do the opposite? I'm not so sure.

And normal Debian users have much less resources than Russia.

Pretending that this refusal to include loadable firmware helps anyone is sanctimony: you give something which can not be ever used without binary blobs (because old system which could be used without binary blobs are fast becoming history and it's not even clear how long Debian would be usable on them) to people yet refuse to support much more benign firmware in WiFi or Sound cards because it's supposed to protect someone… who would that protect and from which disease?

Debian to vote on its firmware path

Posted Sep 6, 2022 14:11 UTC (Tue) by farnz (subscriber, #17727) [Link] (9 responses)

IIUC, AMD-SEV is later in the process; the "binary blob" khim refers to is the firmware blob that runs on a CPU that's just booted up, and first enables "cache-as-RAM" then sets up the DRAM controllers. Without running this firmware blob on your CPU, you have no DRAM, and no cache either.

Now, chances are that this blob is not hugely interesting - it'll be doing the sorts of things needed to do DDR4 training, which aren't scary, but are a decent amount of code (all to handle the fact that real world devices don't stay at a perfectly fixed setting after manufacture, but rather change in behaviour when in the field) - but it's an ideal hiding place for malicious code since it runs first, and sets up the "known good" state for this CPU.

Debian to vote on its firmware path

Posted Sep 7, 2022 1:03 UTC (Wed) by ras (subscriber, #33059) [Link] (8 responses)

> IIUC, AMD-SEV is later in the process; the "binary blob" khim refers to is the firmware blob that runs on a CPU that's just booted up, and first enables "cache-as-RAM" then sets up the DRAM controllers. Without running this firmware blob on your CPU, you have no DRAM, and no cache either.

That probably doesn't matter. This "trust relationship" really means setting up a set of keys the the host doesn't know about. It's the same in principle as the DRM running in the browser. Provided no one can crack the DRM module, the content being sent is safe - despite it being handled by a huge pile of untrusted code. The browser DRM is just software of course, so anyone believing it can't be cracked is in a state of sin. And the "analogue hole" still remains wide open, although it's no so analogue because it's passing through the kernel.

Since the AES keys are in principle a secret tightly held between on CPU TPM, the owner of the VM, and the memory channel doing the encrypting they should be safe from anything that can't see into those things. But this is all provided by AMD. If you don't trust AMD to do it right then it's all over, as they could sabotage the whole thing in a zillion different ways you have no hope of discovering. So 100% trust is a given. The point is you can get away with just trusting AMD, but not the Russian's, despite the Russian's having physical custody of the CPU, and total control of the host OS running the VM - and total access to the memory.

That also applies in reverse. If the Russian's trust AMD 100%, they should be able to run a VM on a AMD-SEV machine controlled by the NSA. But the Russian's trusting a US company who is presumably subservient to the NSA would be quite a stretch, as you say.

Debian to vote on its firmware path

Posted Sep 7, 2022 9:11 UTC (Wed) by farnz (subscriber, #17727) [Link] (7 responses)

The challenging part is that the binary blob is what brings up the memory channel, which is in the trust path. It's entirely plausible that there's debug modes in the memory channel that break your assumptions, and that the binary blob is responsible for locking out into the "production" config. That makes the binary blob running on the CPU during early boot (before UEFI starts up in a traditional firmware) a part of the trusted base for AMD-SEV, and yet it's software-modifiable (stored in the machine's reflashable firmware store).

Further, you have to take updates to this code from your motherboard vendor on trust - you have no easy way to tell whether a given update is direct from AMD, or has been altered by the motherboard vendor on the request of a dodgy agency. This means that your trusted base is not just AMD, but also your motherboard vendor (since they are in a position to install a signing key into the system as a whole that results in the early firmware being trusted) - and potentially everyone who had access to the motherboard before it arrives in your datacentre.

This is why open-source firmware is interesting: you can confirm that the firmware you're running is the firmware you expect and not backdoored by the motherboard vendor (or in transit) since you can replace the flash storage (wiping out old on-CPU TPM keys in the process, since those live in the flash) on arrival, and you know what the firmware you're putting on there does. Your trust base is thus reduced from "is the binary blob the motherboard vendor supplied actually AMD's blob, and does it do what AMD promise" to "does the hardware AMD sold me contain hidden storage, and does it work as promised".

Debian to vote on its firmware path

Posted Sep 7, 2022 10:28 UTC (Wed) by ras (subscriber, #33059) [Link] (6 responses)

> The challenging part is that the binary blob is what brings up the memory channel,

The encryption is done on the CPU die, so I presume the binary blob comes from AMD. As I said, trusting AMD is assumed - and that includes trusting all binary blobs that come from them.

> Further, you have to take updates to this code from your motherboard vendor on trust - you have no easy way to tell whether a given update is direct from AMD, or has been altered by the motherboard vendor on the request of a dodgy agency.

I haven't checked, but surely AMD digital signs their CPU firmware, and the chip only accepts something signed appropriately?

> It's entirely plausible that there's debug modes in the memory channel that break your assumptions,

It doesn't sound too plausible to me. There has been some research into attacks against AMD-SEV already, which have found weaknesses. (I don't know whether they were fatal.) IIRC, they involve modifying the encrypted memory (which of course then yields junk when de-encrypted), and observing what happens when it is used. Repeat that until you see a pattern. It just doesn't sound reasonable they would miss something as obvious as using debug mode to spy on a memory channel.

> This is why open-source firmware is interesting

It is why a totally open source solution is interesting. If the chip is RISC-V, and the VHDL is open source, and you have a "reproducible build" (I have no idea what that would look like for hardware), then there is no need to trust AMD. You can verify it yourself. Of course the firmware must be open source too, because you have to trust the entire stack, just as you say.

But if you don't trust he hardware, all bets are off. It doesn't matter if the firmware is open source or not. There will be non upgradeable ROM firmware on the CPU - even if it's just to load the uploadable RAM replacement. It could be doing anything, including loading your open source firmware then throwing it away. This is why open source firmware alone is not so interesting if you are looking at it from just a security standpoint. It has to be turtles all the way down.

Debian to vote on its firmware path

Posted Sep 7, 2022 12:23 UTC (Wed) by farnz (subscriber, #17727) [Link] (5 responses)

The binary blob that sets up the memory channel is supplied to you by the motherboard manufacturer - and at least the last time I had this level of access, the motherboard manufacturer has the ability to rebuild that blob with changes, because you do want to be able to do things like rule out specific settings that, while legitimate for the CPU, will cause EMC issues because of the specific length of motherboard traces, and to rearrange the order in which different options are tested to increase the chances of finding the right training settings first attempt. That includes the ability for the motherboard manufacturer to sign the blob that goes onto their motherboards, so that the CPU will run it.

And debug modes that are controlled by a one-way disable are not uncommon in hardware design - once the debug mode has been disabled (and the AMD-supplied code will do this for you), it can never be re-enabled at runtime, which makes it useless for researchers (since the normal AMD blob will turn off debug modes before training DRAM, so you have no ability to turn them back on). As there's no visibility into this process, you can't tell if this is going on - you're taking it on trust that AMD either has no ability to debug AMD-SEV silicon bugs (sounds unlikely to me) or has correctly written the binary blob such that it disables debug options before training DRAM, and that no-one who is in a position to tamper with the blob has done so.

With open-source firmware, you would not have to trust that the blob you are running is unmodified from AMD's version and could look for mistakes in the very early bring-up code. It seems unlikely given the research into breaking AMD-SEV that they have badly implemented debug options (it's trivial in ASIC design to design a write-only register that starts up in the "enabled" state, and switches to a hard disabled state on any write, and I would expect AMD to be competent enough to not have debug features turned on when the debug control register is set to a hard disabled state), but that doesn't protect you if the motherboard manufacturer can change the code you run.

Debian to vote on its firmware path

Posted Sep 8, 2022 5:52 UTC (Thu) by ras (subscriber, #33059) [Link] (4 responses)

> The binary blob that sets up the memory channel is supplied to you by the motherboard manufacturer - and at least the last time I had this level of access, the motherboard manufacturer has the ability to rebuild that blob with changes, because you do want to be able to do things like rule out specific settings that, while legitimate for the CPU, will cause EMC issues because of the specific length of motherboard traces, and to rearrange the order in which different options are tested to increase the chances of finding the right training settings first attempt.

Yes, of course. But none of that will allow the firmware blob to see what is in memory. If it did, AMD-SEV would be a lost cause.

The point I was trying to make is this statement by khim is too broad:

> If you want to ensure that your CPU wouldn't be under control of NSA then you first need to design something which doesn't depend on binary blobs to, you know, access the RAM.

Untrusted binary blobs running in any card with DMA may well have access to the RAM. Hell, the untrusted drivers in the host OS will probably have access to all of RAM. But we don't need to "first design something" to fix that. AMD-SEV fixes it, and it's available now.

The point khim is making about it being easier to run Windows than it is to run Linux on consumer hardware still stands, of course. I wasn't try to argue against it - it's always been true. And yes that means most people, even college IT students, if forced to use Linux will take the easiest path and just run it under Windows. It's a new(ish) phenomenon. It sounds ominous but it's actually a huge win, because being forced to become familiar with Linux is new. I doubt it was altruistic motives that caused Microsoft to release WSL - it was fear of losing those users, users who will be making corporate IT decisions in the future. And in the meantime the true believers will continue fight tooth and nail to run only open source on bare metal just as they've been doing for the last 25 years. I suspect khim loses sight of the fact that while as a proportion of the "IT industry" the number of true believers is being diluted, I strongly suspect in absolute terms their numbers they have always been growing, and are consequently a much larger force to be reckoned with than 25 years ago. They may never win their fight completely, but I doubt they will ever lose it either.

Debian to vote on its firmware path

Posted Sep 8, 2022 12:57 UTC (Thu) by farnz (subscriber, #17727) [Link] (3 responses)

You are, however, taking it on trust that the version of the blob supplied to AMD's partners only lets them change link training parameters, and can't be modified to run before AMD's part of the blob locks out low-level debug registers (or that AMD's registers for debugging AMD-SEV cannot be misused to compromise AMD-SEV).

While a fully open end-to-end verified system would definitely be nicer, it's still not possible to be 100% confident that AMD-SEV only requires you to trust AMD, and not your motherboard manufacturer with the current setup; in theory, AMD could separate out the part of the blob that does cache-as-RAM setup and also takes responsibility for locking out debug registers from the part that does DRAM link training, and allow you to confirm that the AMD blob is signed separately to the motherboard vendor blob, but that's not how it works today - instead, the early boot code is a single blob, and you can't tell if it's AMD's blob or not.

As it is, though, it's not implausible that AMD has debug registers that can be locked out with a single MSR write, and that cause AMD-SEV to make the encryption key visible to a debugging system (either via software, or to external hardware attached to the CPU under test). In normal operation, those registers would be locked out before DRAM training happens (hence before AMD-SEV is relevant), but a modified blob would be able to leave those registers exposed.

And this is the deep-seated trouble with completely closed firmware like the DRAM training firmware for Intel + AMD CPUs; we don't know what it actually does, and therefore whether there's a trust boundary between AMD/Intel and the motherboard vendor, or whether the actual design merges them together for the purposes of trust.

Debian to vote on its firmware path

Posted Sep 9, 2022 5:41 UTC (Fri) by ras (subscriber, #33059) [Link] (2 responses)

> While a fully open end-to-end verified system would definitely be nicer, it's still not possible to be 100% confident that AMD-SEV only requires you to trust AMD

You are saying because there may be bugs / mistakes in AMD's implementation, it's not possible to be 100% confident AMD-SEV works as advertised. That is totally correct. In fact if someone offered me a bet that someone will find a way past it in the next decade years, I'd take it. (If it was Intel SGX, I'd be happy to reduce the period to months.)

But it's an impossible standard. Flip the argument. Lets say it was all open source. Would it be possible to be 100% confident and say there are no bugs and thus 100% trustworthy? Of course not. I'd be happy to take the same bet.

I'll let you ruminate on where that leaves us, but clearly it isn't: Security is complex. All complex technology has bugs. Ergo we can't 100% trust the security of our systems. (I hold those statements as self-evident.) Therefore we should give up on security.

And no, open source does not solve that problem.

Debian to vote on its firmware path

Posted Sep 9, 2022 8:44 UTC (Fri) by farnz (subscriber, #17727) [Link] (1 responses)

No - I'm making a much more subtle argument than that, relating to the size of my trust base.

I have to trust AMD's designs, and AMD's manufacturing partner for silicon, when using AMD CPUs. That's just a fact of life as it is at the moment; if I used Intel CPUs, I'd just change the word AMD for Intel in that sentence, and it'd still hold true (albeit that Intel current manufacture their own chips). Same applies for any CPU vendor - I trust that vendor's designs, and I trust that their manufacturing will implement the design as created by the vendor, not a modified version to target me.

That is the core trust base I have when using any CPU - I can't avoid trusting the designer and the manufacturer of the silicon. Beyond that, my trust base can be extended by design decisions - for example, in a traditional cloud system (without AMD-SEV), I must also trust the motherboard manufacturer, the BIOS vendor, the DIMM manufacturer, the DRAM chip maker, the hypervisor vendor, the hypervisor operator, and the datacenter owner.

The promise of AMD-SEV is that I no longer need to trust as large a trust base, because AMD-SEV uses cryptography to remove all but AMD from the trust base. I still have to trust AMD and whoever made the CPU, but I no longer have to trust all the other parties involved, since they can only see encrypted data, and cannot get the key. The value of this promise is, however, weakened by the fact that we can't see into the memory controller startup blob - because it is entirely opaque, there is a reasonable possibility that AMD used the startup blob to disable AMD-SEV debug features that break the promises of AMD-SEV (and I would consider having these features that can be disabled in a one-way operation to be entirely reasonable on AMD's part - they need to be able to debug things if their chips misbehave in their labs). And because there is one combined blob that contains both AMD-supplied code and motherboard vendor code, the effect of this is to widen my trust base for AMD-SEV from "just AMD" to "AMD and the motherboard vendor".

There's at least two routes AMD could take to reduce the size of the trust base back down to that promised by AMD-SEV:

  1. Split the blob. Have two blobs, one from AMD that does cache-as-RAM setup and anything needed to make AMD-SEV safe, and a second from the motherboard vendor that does the DRAM training. This would allow me to verify that the AMD blob is indeed from AMD, without needing to trust the motherboard vendor too.
  2. Open up the AMD parts of the blob - fully describe the blob and its system accesses, so that I can validate that the blob from my motherboard vendor only touches the registers that are involved in DRAM training (and thus can be confident that I only need to trust AMD, since my motherboard vendor has done nothing that AMD say is suspicious).

Both work - you will notice that one of them doesn't even involve opening up the blob. But unless AMD do one of the two options, I have no way of telling whether or not the blob expands my trust domain to include the motherboard vendor, or whether it in fact limits me to just trusting AMD because the motherboard vendor modifications aren't able to affect AMD-SEV.

Debian to vote on its firmware path

Posted Sep 9, 2022 9:41 UTC (Fri) by paulj (subscriber, #341) [Link]

"albeit that Intel current manufacture their own chips"

Not sure if that will be true for much longer, least universally. E.g., the information on the new Ponte Vecchio HPC chips is that some of the tiles in the package will be produced by TSMC. The same sources that broke this (now confirmed) also say Intel has plans to have TSMC produce some CPUs.

Debian to vote on its firmware path

Posted Sep 2, 2022 10:56 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

> Well it was pretty widely reported the FBI talked to Microsoft about making sure bitlocker didn't cause them problems. They do care about compromising systems at scale. The NSA also cares about this and have compromised NIST standards in the past.

Wasn't there an NSA key found in BitLocker, or some other encryption facility within Windows?

Debian to vote on its firmware path

Posted Sep 13, 2022 21:12 UTC (Tue) by brunowolff (guest, #71160) [Link]

There was, but IMO the best explanation I saw for this was to allow for Windows to trust some software signed by the NSA to make it easier for them to use Windows in house, rather than an attack on general Windows users.

Debian to vote on its firmware path

Posted Aug 31, 2022 20:11 UTC (Wed) by IanKelling (subscriber, #89418) [Link] (8 responses)

> In 2022 the FSF is a non-entity

How do you think the FSF could be "an entity", or at least a non-non-entity? I work at FSF and I'm doing things for it or thinking about it for most of my waking hours. Please let us know, contact@fsf.org, iank@fsf.org or comment here: I'll read all comments and reply to almost any email.

Debian to vote on its firmware path

Posted Aug 31, 2022 21:23 UTC (Wed) by bluca (subscriber, #118303) [Link] (6 responses)

The only thing the FSF has produced in the past 15 years is awkwardness. Nothing else worth of note. In fact, more and more projects are distancing themselves from it, mainly because it's _still_ led by a person well past the due date.

In the past 10 years there have been two massive, influential and high-impact events regarding open and free drivers: the open sourcing and upstreaming of the AMD graphics drivers, and the open sourcing (hopefully followed in some years by upstreaming) of the NVIDIA graphics drivers. Both of these are events with massive, positive implications that will be felt for decades to come, and have and will change the Linux-on-real-hardware story for the better in a way that nobody ever saw coming.
The FSF (and Debian pretendy's freeness and """pressure""" via making it hard to use actual existing hardware with those components) had absolutely nothing to do with any of it. Zero. Zilch. Nil.

Debian to vote on its firmware path

Posted Sep 2, 2022 16:53 UTC (Fri) by hkario (subscriber, #94864) [Link] (5 responses)

nVidia drivers have been open sourced in a way that completely doesn't matter for actually having open-source only stack running—it's still impossible and will be impossible for the foreseeable future

Debian to vote on its firmware path

Posted Sep 2, 2022 19:23 UTC (Fri) by bluca (subscriber, #118303) [Link] (4 responses)

It is a first and very much necessary step. Not only, it's the most difficult one. It will take a long time, but the only thing required now is time and involvement from technical experts, who are already there and at work. The major obstacle was the legal one, and it's now gone.

Debian to vote on its firmware path

Posted Sep 3, 2022 5:13 UTC (Sat) by pabs (subscriber, #43278) [Link] (3 responses)

As I understood it, the nvidia GPU firmware is signed, so there is zero chance this will ever be free, unless nvidia are planning on publicly releasing their private keys (as Intel do for some audio devices that run SOF) or releasing new GPUs that do not check firmware signatures?

The non-free userspace on the other hand could be reverse-engineered and replaced by nouveau folks, now that they can use the same firmware as the non-free userspace. Or nvidia could release their code, but I haven't seen any indication that they plan to do that?

Debian to vote on its firmware path

Posted Sep 3, 2022 19:32 UTC (Sat) by bluca (subscriber, #118303) [Link] (2 responses)

Talking about drivers here, not firmware

Debian to vote on its firmware path

Posted Sep 4, 2022 0:12 UTC (Sun) by pabs (subscriber, #43278) [Link] (1 responses)

The freeing of the Linux kernel driver (and the common firmware) was welcome indeed, but there is still the matter of the userspace portion of the driver, I haven't seen any indication nvidia plan to open that up. Hopefully nouveau folks can do reverse engineering but they will likely always be playing catch-up as nvidia release new GPUs and drivers.

Debian to vote on its firmware path

Posted Sep 4, 2022 0:13 UTC (Sun) by pabs (subscriber, #43278) [Link]

Woops, didn't mean to imply the firmware was freed, just that making the firmware available in a way that nouveau can use it too is welcome.

Debian to vote on its firmware path

Posted Sep 1, 2022 2:07 UTC (Thu) by willy (subscriber, #9762) [Link]

Still not interested in the FSF while RMS remains on the board. I know you're part of the new generation, but the rest of the board aren't making way fast enough.

Debian to vote on its firmware path

Posted Aug 31, 2022 12:45 UTC (Wed) by elagost (guest, #159111) [Link] (3 responses)

Many of my systems work just fine without non-free firmware. I deliberately buy/hoard ath9k wireless cards, and usually Debian on laptops that are older than the current stable release. These usually have no problems working. Desktops and servers and vms don't need it either. I believe anyone choosing to use Debian for Freedom reasons will do the same. I also don't believe there's a significant amount of people installing Debian that don't know what non-free firmware is, and don't know how to enable it after install, or use the non-free installer image. Giving it priority would be nice, instead of having to rely on searches and bookmarks.

Debian can choose to be
1) Free Software, that is as convenient as it can be, without compromising values
2) Convenient software, that is as Free as it can be, without compromising convenience

Unfortunately I think that this is moving Debian, one of the few 1s out there, into a 2.

Debian to vote on its firmware path

Posted Aug 31, 2022 13:29 UTC (Wed) by santiago (subscriber, #105758) [Link]

If your systems are running on Intel or AMD CPUs, you may also want to install their non-free microcode, at least if you want to follow security updates:

https://wiki.debian.org/Microcode

Debian to vote on its firmware path

Posted Aug 31, 2022 15:43 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

> I also don't believe there's a significant amount of people installing Debian that don't know what non-free firmware is, and don't know how to enable it after install, or use the non-free installer image.

That is the problem they are trying to solve. Regular people don't know how to install Debian, in part because trying to install Debian (in the obvious way, i.e. with the official installer) results in a machine that either won't boot or can't go online, and in part because Debian is obscure relative to "the mainstream" (i.e. Windows and macOS). There's not much that can be done about the latter, but at least the former is a solvable problem.

Debian to vote on its firmware path

Posted Aug 31, 2022 17:20 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

I strongly suspect that all your systems rely on non-free firmware, they just don't rely on it being provided by the OS

Debian to vote on its firmware path

Posted Aug 31, 2022 13:36 UTC (Wed) by scientes (guest, #83068) [Link] (2 responses)

I second the resolution to include non-free firmware (which is not part or Debian) on the Debian install CD for the purposes of bootstrapping development of non-free software and increasing the chance on a successful first experience with GNU/Linux.

I have had multiple computer which have co-processors (such ad Intel vPro or the Pinebook modem co-processor, which runs a rare ISA) rooting my Debian systems, and there is lots of non-free firmware on a system (such as SSD FTLs) which simply lives outsude Debian. It is miopic to think that impairing people's ability to get a functioning system (and I recommend the vrms package) helps advance free software.

I suggest offering a list of hardware that non-free firmware and drivers have abandoned, on Linux. (Certainly has happened to me.) And that such pronoems simply cannot be fixed, and the Debian project sinply cannot do anything about such problems.

Debian to vote on its firmware path

Posted Aug 31, 2022 16:08 UTC (Wed) by IanKelling (subscriber, #89418) [Link]

> for the purposes of bootstrapping development of non-free software

I think you intended to write "free software." Hopefully I'm clarifying things for other readers of your comment.

Debian to vote on its firmware path

Posted Sep 1, 2022 1:30 UTC (Thu) by pabs (subscriber, #43278) [Link]

Debian certainly can do things to improve the non-free firmware situation, one example would be to fund existing firmware liberation projects.

https://salsa.debian.org/debian/grow-your-ideas/-/issues/39
https://wiki.debian.org/Firmware/Open

For example it was mentioned on #debian-raspberrypi by the person working on the librerpi firmware for RPi devices that their oscilloscope has low resolution. We could buy them a better oscilloscope to start with.

https://github.com/librerpi

Debian to vote on its firmware path

Posted Sep 1, 2022 15:32 UTC (Thu) by flussence (guest, #85566) [Link] (3 responses)

When I install Debian it asks me if I'd like to go through the entire list of CA certificates and audit them one by one. It *could* provide a completely indecipherable list like that for firmware files. It could *pre-fill* selections and tell me which hardware components and drivers they correspond to. It could present shopping lists of alternative hardware for people who *want* to be evangelical fundamentalists about their little lump of battery-powered sand.

But instead we have the software freedom equivalent of US airport security circa 2002. Users are conditioned to sideload contraband blobs like they're pirating Android apps. This distro's status quo of telling users they're going to hell because their PC possesses original sin is untenable, obnoxious, counterproductive, and needed to stop years ago.

Don't call it a "universal operating system" if you're going to be like that; if people really want smug lectures for failing Some Random Computer Guy's purity test they can go use GNUisance or whatever. Kick that guy out while you're at it.

Debian to vote on its firmware path

Posted Sep 2, 2022 0:22 UTC (Fri) by pabs (subscriber, #43278) [Link] (2 responses)

I've never seen that CA list at installation time, did you put the installer into expert mode?

Debian to vote on its firmware path

Posted Sep 3, 2022 16:22 UTC (Sat) by cortana (subscriber, #24596) [Link] (1 responses)

Maybe they mean when ca-certificates is upgraded--ISTR being asked which newly-added authorities I wanted to enable one by one, as if I have any idea!

Debian to vote on its firmware path

Posted Sep 9, 2022 20:48 UTC (Fri) by flussence (guest, #85566) [Link]

Yes that sounds more plausible, thanks for clearing that up. Those ncurses things have a bit of a "chicken chicken chicken" problem.

(OTOH you've now reminded me of how Debian has a bizarre inversion of control regarding where it asks for user input and where it does things completely automatically - like starting listening services)


Copyright © 2022, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds