Debian to vote on its firmware path
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.
Posted Aug 31, 2022 6:43 UTC (Wed)
by patrakov (subscriber, #97174)
[Link] (28 responses)
Posted Aug 31, 2022 8:09 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link] (23 responses)
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.
Posted Aug 31, 2022 8:57 UTC (Wed)
by bluca (subscriber, #118303)
[Link]
Posted Aug 31, 2022 9:42 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (16 responses)
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.
Posted Aug 31, 2022 10:33 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
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,
Posted Aug 31, 2022 18:40 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link] (14 responses)
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.
Posted Aug 31, 2022 19:17 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (4 responses)
Posted Sep 6, 2022 22:41 UTC (Tue)
by IanKelling (subscriber, #89418)
[Link] (3 responses)
Posted Sep 6, 2022 22:54 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Sep 7, 2022 6:37 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link] (1 responses)
Posted Sep 8, 2022 2:35 UTC (Thu)
by pabs (subscriber, #43278)
[Link]
https://www.usenix.org/conference/usenixsecurity17/techni...
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.
Posted Aug 31, 2022 19:51 UTC (Wed)
by pizza (subscriber, #46)
[Link] (8 responses)
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.
Posted Aug 31, 2022 23:40 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link] (7 responses)
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.
Posted Aug 31, 2022 23:42 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link]
Posted Sep 1, 2022 13:44 UTC (Thu)
by IanKelling (subscriber, #89418)
[Link]
Posted Sep 3, 2022 1:38 UTC (Sat)
by KJ7RRV (subscriber, #153595)
[Link] (4 responses)
* Manufacturer cannot rewrite firmware
Device with rewritable, nonfree firmware (device B):
* Manufacturer can rewrite firmware, but only with your permission (you can refuse the update)
Device with rewritable, free firmware (device A):
* Manufacturer can rewrite firmware, but only with your permission (you can refuse the update)
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?
Posted Sep 3, 2022 11:35 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link]
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.
Posted Sep 5, 2022 8:39 UTC (Mon)
by geert (subscriber, #98403)
[Link] (1 responses)
Option B gives the manufacturer the power to make the device unusable, which is not the case with option A.
Posted Sep 5, 2022 10:26 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Sep 6, 2022 21:29 UTC (Tue)
by IanKelling (subscriber, #89418)
[Link]
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.
Posted Aug 31, 2022 13:51 UTC (Wed)
by jbicha (subscriber, #75043)
[Link]
Posted Aug 31, 2022 14:53 UTC (Wed)
by developer122 (guest, #152928)
[Link] (1 responses)
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.
Posted Aug 31, 2022 23:48 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link]
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...
Posted Aug 31, 2022 21:40 UTC (Wed)
by dvrabel (subscriber, #9500)
[Link]
Posted Aug 31, 2022 23:00 UTC (Wed)
by moxfyre (guest, #13847)
[Link]
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.
Posted Aug 31, 2022 20:09 UTC (Wed)
by bartoc (guest, #124262)
[Link] (3 responses)
Posted Aug 31, 2022 21:32 UTC (Wed)
by brunowolff (guest, #71160)
[Link] (1 responses)
Posted Sep 1, 2022 6:51 UTC (Thu)
by johill (subscriber, #25196)
[Link]
Happy to be proven wrong if they fixed it somehow in the 10+ years I wasn't looking.
Posted Sep 1, 2022 1:42 UTC (Thu)
by pabs (subscriber, #43278)
[Link]
Posted Aug 31, 2022 7:47 UTC (Wed)
by taladar (subscriber, #68407)
[Link] (1 responses)
Posted Aug 31, 2022 15:35 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link]
Posted Aug 31, 2022 8:01 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link] (51 responses)
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... .
Posted Aug 31, 2022 8:44 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link] (49 responses)
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?
Posted Aug 31, 2022 9:25 UTC (Wed)
by amacater (subscriber, #790)
[Link] (45 responses)
Debian _does_ work on a huge variety of hardware: the problem is that most laptops from the last few years require at least
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]
Posted Aug 31, 2022 9:33 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (20 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.
Posted Aug 31, 2022 10:57 UTC (Wed)
by chris_se (subscriber, #99706)
[Link] (2 responses)
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?
Posted Aug 31, 2022 12:36 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link]
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.
Posted Aug 31, 2022 15:25 UTC (Wed)
by passthejoe (guest, #156034)
[Link]
But the issue for me is if you can't boot or get internet, you really can't exercise any "freedom."
Posted Aug 31, 2022 11:34 UTC (Wed)
by stevem (subscriber, #1512)
[Link] (13 responses)
Posted Sep 1, 2022 0:33 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (4 responses)
Posted Sep 1, 2022 17:19 UTC (Thu)
by jbicha (subscriber, #75043)
[Link] (2 responses)
Posted Sep 1, 2022 17:35 UTC (Thu)
by amacater (subscriber, #790)
[Link]
Posted Sep 4, 2022 11:39 UTC (Sun)
by pabs (subscriber, #43278)
[Link]
Posted Sep 1, 2022 17:32 UTC (Thu)
by stevem (subscriber, #1512)
[Link]
Posted Sep 1, 2022 20:59 UTC (Thu)
by amarao (guest, #87073)
[Link] (7 responses)
Posted Sep 1, 2022 21:50 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (5 responses)
Cheers,
Posted Sep 2, 2022 2:54 UTC (Fri)
by amarao (guest, #87073)
[Link] (1 responses)
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:
I don't really like side B, because it's unreasonable demand from unrelated people.
Posted Sep 2, 2022 6:22 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Posted Sep 2, 2022 6:15 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Posted Sep 3, 2022 16:12 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (1 responses)
(Don't tell me it's small enough to be included in the intel-microcode package!?!?)
Posted Sep 4, 2022 0:08 UTC (Sun)
by pabs (subscriber, #43278)
[Link]
Posted Sep 3, 2022 4:10 UTC (Sat)
by pabs (subscriber, #43278)
[Link]
Posted Aug 31, 2022 16:09 UTC (Wed)
by brunowolff (guest, #71160)
[Link]
Posted Aug 31, 2022 22:55 UTC (Wed)
by moxfyre (guest, #13847)
[Link] (1 responses)
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:
Posted Sep 1, 2022 0:41 UTC (Thu)
by pabs (subscriber, #43278)
[Link]
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.
There are other free WiFi firmware projects btw. All for very old devices and standards indeed though: open-ath9k-htc-firmware, carl9170fw, Prism54 FreeMAC
Posted Aug 31, 2022 15:57 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link] (23 responses)
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.
Posted Aug 31, 2022 16:54 UTC (Wed)
by amacater (subscriber, #790)
[Link] (6 responses)
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.
Posted Aug 31, 2022 18:25 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link] (2 responses)
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.
Posted Aug 31, 2022 18:38 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (1 responses)
Posted Sep 6, 2022 21:17 UTC (Tue)
by IanKelling (subscriber, #89418)
[Link]
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.
Posted Sep 1, 2022 1:35 UTC (Thu)
by pabs (subscriber, #43278)
[Link]
Posted Sep 1, 2022 10:42 UTC (Thu)
by paulj (subscriber, #341)
[Link] (1 responses)
Vendors in this space are really worth supporting, and I think I will with my next hardware purchase later this year.
Posted Sep 1, 2022 11:58 UTC (Thu)
by brunowolff (guest, #71160)
[Link]
Posted Aug 31, 2022 23:19 UTC (Wed)
by moxfyre (guest, #13847)
[Link] (15 responses)
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.
Posted Sep 1, 2022 1:18 UTC (Thu)
by khim (subscriber, #9252)
[Link] (11 responses)
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. 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”.
Posted Sep 1, 2022 15:46 UTC (Thu)
by pizza (subscriber, #46)
[Link]
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!
Posted Sep 2, 2022 5:08 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (9 responses)
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.
Posted Sep 2, 2022 7:14 UTC (Fri)
by khim (subscriber, #9252)
[Link] (4 responses)
Yes, you can. Sure, but why is that a problem? 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.
Posted Sep 4, 2022 7:33 UTC (Sun)
by LtWorf (subscriber, #124958)
[Link] (3 responses)
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.
Posted Sep 4, 2022 11:22 UTC (Sun)
by khim (subscriber, #9252)
[Link] (2 responses)
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. 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. 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? 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.
Posted Sep 5, 2022 17:23 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
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 :)
Posted Sep 5, 2022 18:17 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link]
Why would someone who wants WSL install windows? Their computer probably came with it pre-installed.
Posted Sep 2, 2022 14:42 UTC (Fri)
by pizza (subscriber, #46)
[Link] (3 responses)
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.
Posted Sep 2, 2022 14:55 UTC (Fri)
by amacater (subscriber, #790)
[Link] (1 responses)
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.
Posted Sep 2, 2022 16:40 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
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.)
Posted Sep 6, 2022 8:34 UTC (Tue)
by geert (subscriber, #98403)
[Link]
Posted Sep 1, 2022 1:39 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (2 responses)
Posted Sep 1, 2022 11:39 UTC (Thu)
by excors (subscriber, #95769)
[Link] (1 responses)
(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.)
Posted Sep 3, 2022 4:04 UTC (Sat)
by pabs (subscriber, #43278)
[Link]
Posted Aug 31, 2022 23:29 UTC (Wed)
by moxfyre (guest, #13847)
[Link] (2 responses)
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?
Posted Sep 13, 2022 0:15 UTC (Tue)
by ayay (guest, #144420)
[Link] (1 responses)
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.
Posted Sep 13, 2022 6:49 UTC (Tue)
by LtWorf (subscriber, #124958)
[Link]
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.
Posted Sep 13, 2022 0:01 UTC (Tue)
by ayay (guest, #144420)
[Link]
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.
Posted Aug 31, 2022 9:19 UTC (Wed)
by chris_se (subscriber, #99706)
[Link] (3 responses)
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.
Posted Aug 31, 2022 9:27 UTC (Wed)
by pabs (subscriber, #43278)
[Link]
https://github.com/meklort/bcm5719-fw
Posted Aug 31, 2022 16:37 UTC (Wed)
by mfuzzey (subscriber, #57966)
[Link]
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.
Posted Sep 1, 2022 1:34 UTC (Thu)
by khim (subscriber, #9252)
[Link]
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?
Posted Aug 31, 2022 10:51 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (51 responses)
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:
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.
Posted Aug 31, 2022 14:07 UTC (Wed)
by pizza (subscriber, #46)
[Link] (41 responses)
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.
Posted Aug 31, 2022 15:33 UTC (Wed)
by brunowolff (guest, #71160)
[Link] (40 responses)
It is possible to buy motherboards where source to the firmware and schematics are available for the whole thing for Power 9. Power 9
Posted Aug 31, 2022 19:14 UTC (Wed)
by WolfWings (subscriber, #56790)
[Link] (6 responses)
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.
Posted Sep 1, 2022 8:27 UTC (Thu)
by brunowolff (guest, #71160)
[Link] (3 responses)
Posted Sep 1, 2022 15:40 UTC (Thu)
by pizza (subscriber, #46)
[Link]
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.
Posted Sep 2, 2022 0:14 UTC (Fri)
by pabs (subscriber, #43278)
[Link]
Posted Sep 3, 2022 9:07 UTC (Sat)
by joib (subscriber, #8541)
[Link]
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.)
Posted Sep 1, 2022 9:46 UTC (Thu)
by paulj (subscriber, #341)
[Link] (1 responses)
They're doing this not for ideological reasons, but because of the security implications of proprietary firmware.
Posted Sep 1, 2022 9:48 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Posted Aug 31, 2022 20:24 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link] (2 responses)
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.
Posted Sep 4, 2022 23:33 UTC (Sun)
by intelfx (subscriber, #130118)
[Link] (1 responses)
What you have is a ridiculously rare exception.
Posted Sep 5, 2022 10:14 UTC (Mon)
by atnot (subscriber, #124910)
[Link]
Posted Sep 1, 2022 1:44 UTC (Thu)
by khim (subscriber, #9252)
[Link] (29 responses)
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?
Posted Sep 1, 2022 2:08 UTC (Thu)
by rodgerd (guest, #58896)
[Link]
Posted Sep 1, 2022 8:48 UTC (Thu)
by brunowolff (guest, #71160)
[Link] (27 responses)
Posted Sep 1, 2022 9:59 UTC (Thu)
by bluca (subscriber, #118303)
[Link] (2 responses)
Posted Sep 1, 2022 11:23 UTC (Thu)
by brunowolff (guest, #71160)
[Link] (1 responses)
Posted Sep 1, 2022 15:39 UTC (Thu)
by khim (subscriber, #9252)
[Link]
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? 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. 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. 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? 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. 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?
Posted Sep 1, 2022 10:59 UTC (Thu)
by khim (subscriber, #9252)
[Link] (23 responses)
The same can be said about Windows in case when you use it to run Linux in WSL. 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. 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. 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.
Posted Sep 1, 2022 11:47 UTC (Thu)
by brunowolff (guest, #71160)
[Link] (22 responses)
> 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.
Posted Sep 1, 2022 16:16 UTC (Thu)
by khim (subscriber, #9252)
[Link] (21 responses)
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? 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). 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. 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 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.
Posted Sep 1, 2022 17:06 UTC (Thu)
by brunowolff (guest, #71160)
[Link] (20 responses)
> 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.)
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.
Posted Sep 1, 2022 18:18 UTC (Thu)
by khim (subscriber, #9252)
[Link] (17 responses)
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. 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 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”. Who would give it encrypted blobs? OS? Where would that OS come from? And I'm talking about devices that FSF actually recommends. Old crippled ThinkPads with no boot verification, mostly. 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.
Posted Sep 1, 2022 18:59 UTC (Thu)
by brunowolff (guest, #71160)
[Link] (4 responses)
> 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.
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”.
> 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
> 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.
Posted Sep 1, 2022 19:20 UTC (Thu)
by pizza (subscriber, #46)
[Link]
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_.
Posted Sep 1, 2022 19:27 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
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.
Posted Sep 1, 2022 19:34 UTC (Thu)
by brunowolff (guest, #71160)
[Link]
Posted Sep 1, 2022 19:42 UTC (Thu)
by brunowolff (guest, #71160)
[Link]
Posted Sep 6, 2022 10:59 UTC (Tue)
by ras (subscriber, #33059)
[Link] (11 responses)
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.
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?
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.
Posted Sep 7, 2022 1:03 UTC (Wed)
by ras (subscriber, #33059)
[Link] (8 responses)
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.
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".
Posted Sep 7, 2022 10:28 UTC (Wed)
by ras (subscriber, #33059)
[Link] (6 responses)
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.
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.
Posted Sep 8, 2022 5:52 UTC (Thu)
by ras (subscriber, #33059)
[Link] (4 responses)
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.
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.
Posted Sep 9, 2022 5:41 UTC (Fri)
by ras (subscriber, #33059)
[Link] (2 responses)
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.
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:
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.
Posted Sep 9, 2022 9:41 UTC (Fri)
by paulj (subscriber, #341)
[Link]
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.
Posted Sep 2, 2022 10:56 UTC (Fri)
by paulj (subscriber, #341)
[Link] (1 responses)
Wasn't there an NSA key found in BitLocker, or some other encryption facility within Windows?
Posted Sep 13, 2022 21:12 UTC (Tue)
by brunowolff (guest, #71160)
[Link]
Posted Aug 31, 2022 20:11 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link] (8 responses)
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.
Posted Aug 31, 2022 21:23 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (6 responses)
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.
Posted Sep 2, 2022 16:53 UTC (Fri)
by hkario (subscriber, #94864)
[Link] (5 responses)
Posted Sep 2, 2022 19:23 UTC (Fri)
by bluca (subscriber, #118303)
[Link] (4 responses)
Posted Sep 3, 2022 5:13 UTC (Sat)
by pabs (subscriber, #43278)
[Link] (3 responses)
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?
Posted Sep 3, 2022 19:32 UTC (Sat)
by bluca (subscriber, #118303)
[Link] (2 responses)
Posted Sep 4, 2022 0:12 UTC (Sun)
by pabs (subscriber, #43278)
[Link] (1 responses)
Posted Sep 4, 2022 0:13 UTC (Sun)
by pabs (subscriber, #43278)
[Link]
Posted Sep 1, 2022 2:07 UTC (Thu)
by willy (subscriber, #9762)
[Link]
Posted Aug 31, 2022 12:45 UTC (Wed)
by elagost (guest, #159111)
[Link] (3 responses)
Debian can choose to be
Unfortunately I think that this is moving Debian, one of the few 1s out there, into a 2.
Posted Aug 31, 2022 13:29 UTC (Wed)
by santiago (subscriber, #105758)
[Link]
Posted Aug 31, 2022 15:43 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link]
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.
Posted Aug 31, 2022 17:20 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link]
Posted Aug 31, 2022 13:36 UTC (Wed)
by scientes (guest, #83068)
[Link] (2 responses)
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.
Posted Aug 31, 2022 16:08 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link]
I think you intended to write "free software." Hopefully I'm clarifying things for other readers of your comment.
Posted Sep 1, 2022 1:30 UTC (Thu)
by pabs (subscriber, #43278)
[Link]
https://salsa.debian.org/debian/grow-your-ideas/-/issues/39
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.
Posted Sep 1, 2022 15:32 UTC (Thu)
by flussence (guest, #85566)
[Link] (3 responses)
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.
Posted Sep 2, 2022 0:22 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (2 responses)
Posted Sep 3, 2022 16:22 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (1 responses)
Posted Sep 9, 2022 20:48 UTC (Fri)
by flussence (guest, #85566)
[Link]
(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)
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Wol
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
https://github.com/RUB-SysSec/Microcode
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
* You cannot rewrite firmware
* 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
* You can run your own custom firmware
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Wol
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
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
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
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.
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.
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
We need to draw a line somewhere. This seems a reasonable place for me...
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
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
Debian to vote on its firmware path
Debian to vote on its firmware path
Wol
Debian to vote on its firmware path
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.
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
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.
… 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
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Bunny Huang is also doing some interesting development of secure portable/personal devices.
Debian to vote on its firmware path
>
> 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.
> 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.
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
> You can't run graphical applications this way.
Debian to vote on its firmware path
Debian to vote on its firmware path
> Ergonomicity seems like it should be important for such a supposedly perfect for users solution.
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Two different perspectives
Two different perspectives
https://github.com/hlandau/ortega/
https://wiki.debian.org/Firmware/Open#Network
https://wiki.debian.org/Firmware/Open#Radio
Two different perspectives
Sure it isn't considered officially to be "part of Debian" but it is still hosted on Debian's infrastructure.
> If someone has a principled objection to running any non-free firmware at all, the list of hardware they can use is extremely short.
Two different perspectives
Debian to vote on its firmware path
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?
http://ftp.debian.org/debian/pool/non-free/n/nvidia-graph...
Debian to vote on its firmware path
Debian to vote on its firmware path
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
Debian to vote on its firmware path
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
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
> In order for this stuff to become cost competitive
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
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
Debian to vote on its firmware path
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.
> Firmware in mass storage generally isn't going to limit what you want to do if you pass it encrypted data.
Debian to vote on its firmware path
> 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.
Debian to vote on its firmware path
Debian to vote on its firmware path
> Sorry, in my opinion running anything on a recent version of Windows is insane (at least the versions available to consumers).
Debian to vote on its firmware path
Debian to vote on its firmware path
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.
> This couldn't be done if the firmware was fixed in the hardware.
Debian to vote on its firmware path
Debian to vote on its firmware path
.
> 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.
>> 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.
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.
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
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
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
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
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
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
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
https://wiki.debian.org/Firmware/Open
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path