GNU Linux-libre 4.14-gnu Released, Still A Battle Deblobbing Driver Firmware

[phoronix]

Phoronix: GNU Linux-libre 4.14-gnu Released, Still A Battle Deblobbing Driver Firmware

The Free Software Foundation Latin America team are once again punctual in delivering their updated GNU Linux-libre kernel...

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

[uid313]

Seems like a great fit for servers. Since they don't usually rely on proprietary AMD and Nvidia drivers or Wi-Fi.
Maybe deblobbing it would increase security too.

But will this result in the CPU running outdated microcode?

[starshipeleven]

Seems like a great fit for servers.

No, this project is plain useless in real-world applications.

Ethernet controllers need a firmware (Broadcomm/others, not Intel gigabit), Matrox and Aspeed embedded graphics of the IPMI system need a firmware, a bunch of 10Gbit cards need a firmware.

Maybe deblobbing it would increase security too.

Not by any detectable amount. Also the two main security issues on a server are Intel ME and the UEFI firmware, none in his right mind would really bother to hack a rather limited and probably also signed device firmware when they can hack one of the two (buggy) OSes that have full control over the server already (ME and UEFI).

But will this result in the CPU running outdated microcode?

Yes, and this is bad for any system.

[OneBitUser]

Seems like a great fit for servers. Since they don't usually rely on proprietary AMD and Nvidia drivers or Wi-Fi.
Maybe deblobbing it would increase security too.

But will this result in the CPU running outdated microcode?

Please do not confuse this political statement with application software!

[danieru]

Have they fixed the problem they where causing that forced gentoo to remove the deblob useflag?

https://bugs.gentoo.org/537132

Sometimes it works, but when they change the file while keeping the same name it will break. Until that issue is solved by us doing some svn checking, or them by adding a version number when they update the script, then the deblob support for vanilla or gentoo-sources stays removed.

[KRiloshart]

I don't think this gnu project is practical. Every company wants to keep it's trade secrets

When will stallman understand that companies are not charity.

[trek]

> But will this result in the CPU running outdated microcode?
Yes, and this is bad for any system.

I remember when the pentium fdiv bug hit the users, it was fixed with software workarounds at kernel level, without any firmware upgrade (there was no cpu firmware at the time)

at the same time Intel spent $475 millions to recall the defective cpus, so the microcode is very profitable to the chip makers but not to the users, as they will no more receive informations about cpu bugs and how to fix them properly at software level

[starshipeleven]

I remember when the pentium fdiv bug hit the users, it was fixed with software workarounds at kernel level, without any firmware upgrade (there was no cpu firmware at the time)

at the same time Intel spent $475 millions to recall the defective cpus, so the microcode is very profitable to the chip makers but not to the users, as they will no more receive informations about cpu bugs and how to fix them properly at software level

Sorry but if you think you can fix microcode bugs with software you're delusional. You can't compare the complexity of the CPU back then with CPUs now.

You can at most workaround them sacrificing something, any proper fix must be done in microcode.

[FireBurn]

It's not really deblobbing, the blobs don't exist in the kernel tree, this is just ripping drivers out that use or try and load blobs