Debian Considers Changing How It Handles Non-Free Firmware (phoronix.com) 94
"Debian currently doesn't load non-free firmware by default on its systems," reports Phoronix, "even when it means no working hardware support/acceleration without those binary elements. Not loading the non-free firmware can also mean missing out on security updates or for addressing usability issues."
Now the Debian community is discussing three proposals on how non-free firmware should be handled going forward (before a vote in September).
Proposal A and B both start with the same two paragraphs: We will include non-free firmware packages from the "non-free-firmware" section of the Debian archive on our official media (installer images and live images). The included firmware binaries will normally be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.).
When the installer/live system is running we will provide information to the user about what firmware has been loaded (both free and non-free), and we will also store that information on the target system such that users will be able to find it later. The target system will also be configured to use the non-free-firmware component by default in the apt sources.list file. Our users should receive security updates and important fixes to firmware binaries just like any other installed software.
But Proposal A adds that "We will publish these images as official Debian media, replacing the current media sets that do not include non-free firmware packages," while Proposal B says those images "will not replace the current media sets," but will instead be offered alongside them.
And Proposal C? "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.
Now the Debian community is discussing three proposals on how non-free firmware should be handled going forward (before a vote in September).
Proposal A and B both start with the same two paragraphs: We will include non-free firmware packages from the "non-free-firmware" section of the Debian archive on our official media (installer images and live images). The included firmware binaries will normally be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.).
When the installer/live system is running we will provide information to the user about what firmware has been loaded (both free and non-free), and we will also store that information on the target system such that users will be able to find it later. The target system will also be configured to use the non-free-firmware component by default in the apt sources.list file. Our users should receive security updates and important fixes to firmware binaries just like any other installed software.
But Proposal A adds that "We will publish these images as official Debian media, replacing the current media sets that do not include non-free firmware packages," while Proposal B says those images "will not replace the current media sets," but will instead be offered alongside them.
And Proposal C? "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.
Makes sense given the context (Score:5, Informative)
I couldn't really understand why they wanted to do any change until I read through the actual proposal text..
Re: (Score:3)
How about because putting fanaticism over functionality is of no benefit to users? This has always been their problem, happy to submit patches to strip out firmware, rarely submitting patches that actually do any reverse engineering or clean-room reimplementation to provide a practical alternative, then pretending like they've somehow done something to address the problem. I remember when some of these clowns first started posting patches to the lkml, in which they also stripped out GPLed bytecode for thing
Re: (Score:2)
Indeed. The primary effect of not taking firmware updates is that you miss out on all the security fixes and your new devices stop working when faced with old firmware.
The reason a lot of firmware is locked down harder than Fort Knox is that it would be a massive security hole to open it up for any piece of passing malware to mess with. The kind of security hold that you would never know is there and would not be able to remove if you did.
I predict there will be people posting that closed source code is ins
Re: (Score:3)
The reason a lot of firmware is locked down harder than Fort Knox is that it would be a massive security hole to open it up for any piece of passing malware to mess with. The kind of security hold that you would never know is there and would not be able to remove if you did.
The same can be said of any code run on a system, firmware or not. The difference between firmware and everything else however, is the security theater manufacturers put on for the crowds when what they really need it for is control. Most people out there believe in the performance. The reality is that any special code that has ridiculous privileges and no ability to be audited, let alone replaced by the device owner, is the Holy Grail for hackers. Specifically because the owner is powerless to do anything
Re: (Score:2)
Basically, is this actually a common and significant problem? Because the other side is that distributing non-free firmware may run into copyright and/or other legal issues if they're not careful.
Because looking at the problem and the proposals, this could all be solved with a note on the downloads page of "Hey, we've gotten reports that some computers won't run things neede
Security? (Score:2)
Re: (Score:2)
You might not realize you are installing nonfree binaries, or (someone less intelligent than you) might not realize that nonfree binaries are a security risk.
Re:Security? (Score:4, Insightful)
Please explain how nonfree binaries signed by the same manufacturer that made the expansion card you just installed are a *security* risk? (I accept that if they were open source drivers in linux / BSD then ensuring they don't break between kernel changes and getting better performance is easier)
Re: (Score:3)
You don't know what they might have inserted or modified, even with published source code. For closed source, you have _no_ idea what else they might have done without a great deal of resources and tools like a decompiler. One of the best examples of such abuse is when the company that owned Sourceforge repackaged the Windows version of GIMP with pernicious adware added. It wasn't in the GIMP source code, they didn't publish their changes as required by the GPL, and many people seeking a GPL, free software
Re: (Score:2)
the company that owned Sourceforge
Slashdot?
DevShare (Score:4, Informative)
I can't seem to compose a comment explaining the timeline of the DevShare saga without encountering a lameness filter. I'll leave it to Wikipedia's coverage [wikipedia.org].
Re:Security? (Score:4, Informative)
In this specific scenario, they are talking about hotplug firmware, meaning code that is executed on the target device, rather than host CPU. The manufacturer can inject the same level of security problems in device-hosted firmware as they can hotplug. There may be some legitimate trust issues, but you would need to filter out all hardware that *comes* with closed firmware. If you are that diligent, you might as well also know what would be accompanied by closed hotplug firmware and avoid that.
Closed source drivers are still not on the table, so at least this specific measure doesn't change what may/may not be executed in OS context. There's plenty of room for shenanigans running on components of course, but they could just as soon do it using firmware that comes in the device's ROM, so non-free firmware doesn't afford protection.
Re: (Score:2)
You don't know what they might have inserted or modified, even with published source code. For closed source, you have _no_ idea what else they might have done.
But you have just installed their hardware inside your computer. You have _no_ idea what else that might be doing. This is why the security argument always fails for me.
Re: (Score:2)
For the most part, I would think this won't apply. Most firmware is being used on discrete parts which don't have any external connectivity of any sort. On your NIC or BMC, maybe that's a concern, but on other parts it's simply not going to do anything except its single job. It won't be wired up to anything but the parts it needs to control.
Some of these parts do have proper CPUs on them, for example my HBA has a PowerPC processor on it. These are, to all intents and purposes, completely independent com
Re: (Score:1)
Re: (Score:3)
If being able to freely view the source code was a guarantee of being secure
That was never the claim , asshole.
But you knew that.
Re: (Score:2)
If you open the hardware up for any old crusty to change the firmware, then your security problems are real and present, compared to the undintified security flaws of closed source firmware.
Re: (Score:3)
explain how nonfree binaries signed by the same manufacturer that made the expansion card you just installed are a *security* risk?
Explain why you think they aren't, when they clearly are.
You can't blindly trust signing. There are stories here all the time of official keys being used to sign malware. And there are also ways to bypass signing requirements in some cases.
Re: (Score:3)
Non-free firmware that runs in an microcontroller on a graphics, audio, or networking coprocessor is a security risk. This is true whether the non-free firmware is in the coprocessor's flash memory or in the coprocessor's RAM. The only difference here is that Debian plans to offer a disk image containing non-free firmware sent to the coprocessor's RAM during the install-time boot process rather than requiring people who need to use non-free firmware during installation to discard their hardware and replace
Re: (Score:2)
You have already installed the manufacturers hardware in your computer. If you don't trust them then your security is compromised. There is nothing they can't do without a binary firmware blob that they can't do with the hardware __you__ installed for them. (note this is slightly different to having binary only drivers which would have access to parts of the system that the manufacturers hardware doesn't).
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
explain how nonfree binaries signed by the same manufacturer that made the expansion card you just installed are a *security* risk?
Explain why you think they aren't, when they clearly are.
Seeing as you didn't explain why they are, I'll explain why they aren't. You have already installed the manufacturers hardware in your computer. If you don't trust them then your security is compromised. There is nothing they can't do without a binary firmware blob that they can't do with the hardware __you__ installed for them. (note this is slightly different to having binary only drivers which would have access to parts of the system that the manufacturers hardware doesn't).
Re: (Score:2)
Seeing as you didn't explain why they are, I'll explain why they aren't. You have already installed the manufacturers hardware in your computer. If you don't trust them then your security is compromised.
You: explain ...
Me: you can't trust that the firmware comes from the manufacturer
You: the firmware comes from the manufacturer
Me:
Re: (Score:2)
But you trust the hardware from the same manufacturer? Better yet, if the firmware was put on a flash chip on the device, would you trust it then?
Howe about the firmware in the BMC or the BIOS?
Re: (Score:2)
But you trust the hardware from the same manufacturer?
Wow. I mean, wow. Just, wow. Seriously, wow.
Go back and read the whole thread again, and if you still think this response makes sense, just don't. I mean, don't at all. Not at all.
Re: (Score:2)
I'm telling you, these apes can talk, they can type, but they're just mimicking. They're not thinking about any of this, and they're not actually reading what anybody writes. They're only scanning your words to see if you're on their team. If you're not on their team, the select a response from the buffet of responses they've seen given to other people who were on the Wrong Team.
Re: (Score:2)
He said HARDWARE you fuckwit.
If you don't trust the firmware, you can't trust the unknown silicon which can be designed to do anything, and you can't know exactly what without completely reverse engineering it under a microscope.
Re: (Score:2)
Explain why you think they aren't, when they clearly are.
Explain why if open source code is a guarantee of security why so many exploits exist in FOSS, some of them including the very recent and very serious CVE-2021-4034 in Polkit which had been allowed to exist for 12 years?
Re: (Score:2)
Explain why if open source code is a guarantee of security
Dum, de dum dum dumb!
Explain why you think that is the claim.
Re: (Score:2)
sorry?
https://letmegooglethat.com/?q... [letmegooglethat.com]
of course *all* software can have vulnerabilities, but the more software you install and the less control you have over it, the higher the risk. debian, quite sensibly, will not endorse third party binary blobs they can't even review. of course they would never endorse proprietary closed code to begin with, but the added security considerations are obvious.
Re: (Score:2)
Top link was to a driver, not firmware.
As you pointed out - there are issues with both open and closed source software. The "open source security is good" has been disproved so many times (google openssl security if you like!)
Re: (Score:2)
failures don't make it worse than the alternative. there is no total security, it's a process and opensource and disclosure is clearly an improvement over obscurity for that process any day. this is software security 101 and amply proven, even if some heartbleed slipped. but even in the worst case, at the very least it will be always publicly traceable, you will know what happened and why, and who it affects. business' shiny dirty little secrets don't even qualify in that regard.
Re: (Score:2)
Top link was to a driver, not firmware.
As a firmware engineer I have to say, this is one of the stupidest things said in the ocean of stupid that is this thread.
The year is 2022. You still haven't figured out how a WinModem differs from a regular modem? Egads!
Re: (Score:2)
Re: (Score:2)
that would be one of the many distributions that carried that package, yes. and?
Re:Security? (Score:5, Informative)
How exactly is it a security risk, if I do not install nonfree binaries? Sounds like FUD.
If the only firmware that mitigates a security issue is in a non-free binary and you don't install it, you don't get the fix -- duh.
Re: (Score:2)
Which raises an important point. Much of this hardware is already running non-free firmware anyway. Even if it's just a bootloader to enable installation of a binary blob later.
If you leave the bootloader running and you don't load your own firmware, maybe malware can load it instead. Or maybe it can just exploit the bootloader itself.
Re: (Score:1)
Re: (Score:1)
Re:Security? (Score:4, Informative)
Have you ever heard, for example, of Specter?
There are many bugs that require nonfree binaries for patching at hardware level so... be my guest if you want to keep your hardware opened to those attacks...
Re: (Score:2)
Have you ever heard, for example, of Specter?
No, but I've heard of SPECTRE, for which there are mitigations in the Linux kernel. There's no good reason not to deliver new CPU firmware though, free or non-free. The firmware ought to be broken up by device class (if not by device family!) and not dumped in one big package.
Re: (Score:2)
Have you ever heard, for example, of Specter?
No, but I've heard of SPECTRE...
I've heard if SPECTRE...I have watched all of the Sean Connery and Roger Moore James Bond movies. After those 2 major stars the franchise went off a cliff.
Re: (Score:3, Informative)
In the old days the firmware was burnt into EPROMs on whatever expansion card you had. In theory this could be updated but no-one ever did.
Then are stuff got more complex someone had the idea of having the firmware downloaded onto the card by the driver when the computer was booted. This made it nice and easy for updates etc to be applied (by updating the driver).
Then a bunch of open source fanatics decided they wanted to cut off their nose to spit their face and said "give us all your trade secrets and o
Re:Security? (Score:4, Insightful)
And the frequent manufacturer response if they do care about Linux is to shrug and just have their firmware in their device still and fall back on 'users must run update utilities to get updates'.
The hotplug firmware model (and some adapters even supported that as the *update* mechanism, which was nice and transparent) is fantastic, but things like this make hardware manufacturers steer away from it.
Re: (Score:1)
Then are stuff got more complex someone had the idea of having the firmware downloaded onto the card by the driver when the computer was booted. This made it nice and easy for updates etc to be applied (by updating the driver).
Nope. They do that to make the hardware cheaper, by not requiring enough flash to hold the firmware. Nice imagination, though.
Then a bunch of open source fanatics decided they wanted to cut off their nose to spit their face and said "give us all your trade secrets and open source your firmware otherwise we'll say you suck"
And they do suck. Their business model is unsustainable and anti-consumer.
Re: (Score:2)
And they do suck. Their business model is unsustainable and anti-consumer.
A business model where they care about 99.9% of their customers over the other 0.1% is unsustainable?
Re: (Score:2)
In the old days the firmware was burnt into EPROMs on whatever expansion card you had. In theory this could be updated but no-one ever did.
Once upon a time the local electronics parts store did brisk business in EPROM chips, driven mostly by their free service to burn alternate modem firmware onto them. You could upgrade a number of modems from 28.8 (or nearby) to 56.6 using this technique, for about $12.
If you wanted them to swap out the chip for you they charged an extra $20. Still, a lot of people paid this, because $32 was a lot cheaper than a new modem!
Re: (Score:3)
How exactly is it a security risk, if I do not install nonfree binaries? Sounds like FUD.
It's not if you live in an ideal world where you have a totally open hardware platform. However most of us have to deal with the reality that Intel may ship a binary microcode security fix. Even for a project with solid free software credentials like Debian, it doesn't make a lot of sense to make it hard to apply it.
Re: (Score:2)
How exactly is it a security risk, if I do not install nonfree binaries? Sounds like FUD.
It's not if you live in an ideal world where you have a totally open hardware platform. .
If open hardware and software was such a guarantee of security then why have so many seriously major exploits not been found for years in some packages that are parts of every major distro such as CVE-2021-4034 for Polkit that managed to survive 12 years before being found?
Re: (Score:2)
Cherry picking a mistake that was already fixed isn't an argument. It's an admission of bias towards a particular outcome / side.
But to answer your question anyway: Locked down binary blobs are a security risk because you cannot change them. If they are found to be exploitable, you are completely powerless and must rely on the goodwill of the vendor to create an
Re: (Score:2)
If open hardware and software was such a guarantee of security then why have so many seriously major exploits not been found for years in some packages that are parts of every major distro such as CVE-2021-4034 for Polkit that managed to survive 12 years before being found?
I just meant that in an ideal world, you would have the option of a fully open stack with no proprietary firmware. Sure it's not a panacea for all security vulnerabilities but we wouldn't have to deal with crap like Intel only shipping IME in a secure configuration to 'special' customers.
Re:Security? (Score:4, Insightful)
You don't know what's in them, you can't recompile them, and you don't know the environment they were built in. You lose "provenance", the ability to trace the source and contents of software. It's precisely what concerned Richard M. Stallman when he published the Gnu Manifesto and created the Free Software Foundation, which since than has hosted many of the most important components of a Linux operating system besides the kernel itself.
Do you need us to walk through more specific examples?
Re: (Score:2)
I think you misread his statement, he was saying the opposite of what you are saying, that "why should non-free *improve* security?" to which the answer is in the summary: Some devices ship with baked in, vulnerable firmware and hotplug firmware brings security fixes, so you get to choose between old vulnerable non-free and new non-free. In those situations free isn't even an option, so shunning non-free hotplug firmware still means you run non-free firmware, just older firmware.
If you have a choice between
Re: (Score:2)
I was answering an earlier question, which said:
> Please explain how nonfree binaries signed by the same manufacturer that made the expansion card you just installed are a *security* risk?
I'm sorry that Slashdot threading can sometimes be confusing.
Re: (Score:2)
You don't know what's in them, you can't recompile them, and you don't know the environment they were built in. You lose "provenance", the ability to trace the source and contents of software.
You did not have any of that when firmware came in an EEPROM chip in the device.
If it was not a problem then, why is this a problem now?
Re: (Score:2)
Did I say it wasn't a problem then, either?
Re: (Score:2)
Re: (Score:2)
Is this a serious comment?
Wow (Score:2, Interesting)
If the hardware just works, then suddenly there is no reason for the existence of Ubuntu.
Re: (Score:2)
If the hardware just works, then suddenly there is no reason for the existence of Ubuntu.
Yep, because the *only* difference between Debian and Ubuntu is hardware support. The ONLY difference. /sarcasm.
I suspect you either have no idea what Debian is or what Ubuntu is. The two are like apples and oranges of the Linux world (or poo and chocolate depending on how extreme you are on some issues).
Re: (Score:2)
Re: (Score:2)
There's no other important difference, besides that Ubuntu typically is closer to being up to date on package revisions than Debian, and that you can remove systemd from Debian if you're not running GNOME (and why would you be?) Ubuntu's big difference from Debian is snap, which is crap, and is best handled by apt purging it with extreme prejudice.
Ubuntu LTS vs. Debian stable (Score:2)
On average, Ubuntu LTS is about as behind on library functionality as Debian stable. So perhaps one might phrase the difference as "Ubuntu also has a 6-month update track in addition to a Debian-style stable track."
Re: (Score:1)
There are others. Ubuntu has demonstrated hat they care far less about user privacy, by collating user data, and reselling it to Amazon. They've made it much less obvious, since people noticed and became _very_ upset, especially about the default enabled harvesting for all users. It's a problem for Ubuntu, but Ubuntu relies on the income from Amazon, so it's not likely to stop.
Re: (Score:2)
Yep, because the *only* difference between Debian and Ubuntu is hardware support. The ONLY difference.
Of course it's not the only difference. For example, Ubuntu has Snap.
Hardware support is the only benefit Ubuntu provides over Debian.
Re: (Score:2)
I suspect you either have no idea what Debian is or what Ubuntu is. The two are like apples and oranges of the Linux world (or poo and chocolate depending on how extreme you are on some issues).
The person who has no idea would seem to be you if you think comparing Debian to Ubuntu is like comparing an apple to an orange.
Copying the boilerplate (Score:3)
There's no prize for "least useful not-a-summary ever", EditorDavid.
it does suck when (Score:2)
Re: (Score:3)
That's when I use my hootoo AP as an ethernet to wifi gateway. I have a "Driverless" USB2 to Eth100 adapter (I forget the driver, but it's one that's included with everything) which I can use to get there if there's no onboard baseTX eth, or no firmware for same.
Irritating, yes. But not a show stopper...
Re: (Score:2)
I also use an old USB-LAN device. They nearly all use the same chipset, which has long been stable in the Linux kernel. But frankly, it's been quite a long time since I had to do a hardware installation, it's almost all virtual machines these days. And that eliminates a lot of the driver difficulties at installation time. It does limit access to the underlying physical hardware for optimal performance, but I'm not running crypto-miners, more databases and monitoring systems.
Does anyone care if the firmware is free? (Score:4, Insightful)
Re: (Score:2)
Most users just want an OS that works. They don't care if the firmware is free or not. Just make it work
Which is why Ubuntu is so successful.
Debian GNU/Linux cares about software freedom, fanatically so.
Re: (Score:2, Insightful)
fanatically so.
And yet here they are, being pragmatic about it, which seems decidedly un-fanatic.
Re: (Score:1)
Is it possible to be fanatically pragmatic?
Re: (Score:2, Informative)
And yet here they are, being pragmatic about it, which seems decidedly un-fanatic.
No, not really. In this case they looking at an accessibility edge case and are still debating whether to force users who need non-free binaries to jump through hoops or get other distributions so as to not dirty their pure distro.
That is not pragmatic, that is still very much fanatical. A pragmatic approach would be to simply include non-free binaries in the installer to allow necessary accessibility and give the user the option to not install non-free software during the installation process.
But no, we mu
Re: Does anyone care if the firmware is free? (Score:2)
Re: (Score:2, Insightful)
Re: (Score:2)
It's fine as long as there are Debian based distros like Ubuntu which offer that easy experience. I don't think many people installing Debian are complete noobs.
Re: (Score:2)
Most users just want an OS that works. They don't care if the firmware is free or not. Just make it work
Debian is not for most users.
I love it, it's close to perfect for me, ymmv.
Re: (Score:2)
Take it up with Red Hat, systemd was the brainchild of Leonart Pottering over there. Oh, wait, he just left Red Hat and wound up over at Microsoft.
I do wish we had a transcript of that discussion with Red Hat. Modern departures of technical leaders rarely include public announcements of why they left, and this is one such case. I do wonder if Microsoft had already made him the offer when he left Red Hat.
What hardware has non-free firmware? (Score:2)
Just curious.
Re: (Score:2)
Ridiculous amount. I'm going to add all GPUs, Realtek Network and Audio chips.
It's practically unavoidable to use non-free drivers. Adding "non-free" repositories to APT is one of the first things, if not the first, I change when installing fresh Debian. Otherwise, I love Debian distro. I've been through quite a few a decade ago and stayed with Debian since then because it's very reliable/stable when you use a stable release.
nt (Score:2)