GNU Linux-libre 5.2-gnu Blesses Sound Open Firmware, Cleans Other Drivers

[phoronix]

Phoronix: GNU Linux-libre 5.2-gnu Blesses Sound Open Firmware, Cleans Other Drivers

Following last night's Linux 5.2 kernel release, the GNU folks maintaining their GNU Linux-libre off-shoot that de-blobs the kernel of being able to load binary-only firmware/microcode files or the ability to load binary-only kernel modules is out with their re-based kernel...

http://www.phoronix.com/scan.php?page=news_item&px=GNU-Linux-Libre-5.2-Released

[andyprough]

That's pretty funny on SOF, but the announcement reads as though no one ever bothered to ask about it.

On wifi, if Realtek and Intel would open it up a bit more, a huge number of additional systems could be run without having to resort to using an Atheros wifi usb dongle.

[hotaru]

while I'm generally in favor of the idea of running only free software, I've always found Linux-libre's stance on microcode updates a bit odd. not updating the microcode doesn't mean you're not running a binary microcode blob. it just means that you're running the outdated blob embedded in the UEFI firmware or the CPU itself that the CPU manufacturer actually admits is buggy and insecure.

[stormcrow]

If this kernel off-shoot removed the ability to load CPU microcode, they're actually making the system less secure because it's then impossible to upload microcode updates to fix flaws in the CPU. This kind of zealotry can come back and bite you in the ass really hard. Cut off your own nose to spite your neighbor's face. Just because Spectre, MDS, Meltdown, and other security related CPU flaws aren't currently being actively used in exploits doesn't mean they never will be in the future.

That's pretty funny on SOF, but the announcement reads as though no one ever bothered to ask about it.

On wifi, if Realtek and Intel would open it up a bit more, a huge number of additional systems could be run without having to resort to using an Atheros wifi usb dongle.

I've not used Realtek wifi in a while (several years), but most of the Intel wifi (N and AC revisions) hardware I've used in the past few years doesn't require external downloads to function on Ubuntu or OpenSUSE. I'd guess it's because the firmware is probably already included for newer devices and it's likely older devices with the screwy copyright redistribution restriction?

On the other hand, some distributions are more anal about firmware loading. That's one reason I stopped using Debian. They weren't packaging a lot of firmware taken for granted on Ubuntu, OpenSUSE, Fedora, CentOS, etc so I had to deal with non-functional wired NICs that required me to download firmware to make them functional. Unfortunately you can't do that if the NIC is non-functional to begin with because of missing firmware. More aggravation than it's worth.

[andyprough]

I've not used Realtek wifi in a while (several years), but most of the Intel wifi (N and AC revisions) hardware I've used in the past few years doesn't require external downloads to function on Ubuntu or OpenSUSE. I'd guess it's because the firmware is probably already included for newer devices and it's likely older devices with the screwy copyright redistribution restriction?

No, it's because most distros give you the non-libre firmware at installation. Debian does not, which is why you have to load firmware for your NIC cards. Trisquel (libre version of Ubuntu), PureOS (libre version of Debian testing), and Parabola (libre version of Arch) are FSF certified to be free of non-libre bits, and so they do not load any non-libre firmware for you at any time.

[stormcrow]

No, it's because most distros give you the non-libre firmware at installation. Debian does not, which is why you have to load firmware for your NIC cards. Trisquel (libre version of Ubuntu), PureOS (libre version of Debian testing), and Parabola (libre version of Arch) are FSF certified to be free of non-libre bits, and so they do not load any non-libre firmware for you at any time.

I know WHY Debian doesn't do it. I just don't care what FSF certifies as "non-libre". That's a political decision and arguably not-user-friendly zealotry. No skin off my nose if someone wants to use those distros, at least until Spectre/MDS type attacks become mainstream and those boxen get compromised and become a threat to the security of the Internet at large.

[andyprough]

I know WHY Debian doesn't do it. I just don't care what FSF certifies as "non-libre". That's a political decision and arguably not-user-friendly zealotry.

It's not political. Political would be picking winners and losers based on who has the friendliest relations. It's technical. It's a question of "does this bit of code adhere to the strict definition of libre software, or not?"

You may not agree that software should respect the 4 freedoms, that's your choice. But the fact of whether or not it does respect those freedoms is simply a technical issue.

[Shiba]

while I'm generally in favor of the idea of running only free software, I've always found Linux-libre's stance on microcode updates a bit odd. not updating the microcode doesn't mean you're not running a binary microcode blob. it just means that you're running the outdated blob embedded in the UEFI firmware or the CPU itself that the CPU manufacturer actually admits is buggy and insecure.

While that is obviously true, using a newer blob could also mean bringing in new backdoors. As always there's not a right answer, just a choice to be made.

[starshipeleven]

While that is obviously true, using a newer blob could also mean bringing in new backdoors. As always there's not a right answer, just a choice to be made.

the entire concept of "backdoors" in microcode is debatable. It's very low level.

It's not a fully autonomous microcontroller running its own mini-OS like most WIFI-ac chipsets.

[Jabberwocky]

while I'm generally in favor of the idea of running only free software, I've always found Linux-libre's stance on microcode updates a bit odd. not updating the microcode doesn't mean you're not running a binary microcode blob. it just means that you're running the outdated blob embedded in the UEFI firmware or the CPU itself that the CPU manufacturer actually admits is buggy and insecure.

This is one of the reasons why I am not running Linux-libre, on the other side of the coin there are various counterarguments to updating proprietary microcode.

• The end-user does not know if the microcode updates are digitally signed and if the signature is actually secure and not just obscure. There's also the problem of OEMs or third parties leaking secure keys.
• The manufacturer might be trying to workaround a hardware problem that prevents the end-user from issuing a RMA on a part that does not work as advertised. I have witnessed this many times and experienced it once. Example: Part runs at 100% power. Part is promoted, reviewed, and sold. Three months later too many issues so firmware limits part to 70% power.

We might see less buggy and insecure microcode if it wasn't as easy to auto update firmware. It's becoming more popular to release first and complete development after release. Hopefully microcode quality won't reach the low points that we have seen in many applications over the past decade. That said, it's not surprising that Linux-libre exists and I am glad to see people working on it even though I am not using it at the moment.