3 ms·

> linux-libre doesn't want you to know if your distro isn't loading updated microcode, because it's "better" (according to them) to run vulnerable non-updated m

by mbakke 5y ago

> linux-libre doesn't want you to know if your distro isn't loading updated microcode, because it's "better" (according to them) to run vulnerable non-updated microcode This is FUD. The reason it's not possible to load microcode or other proprietary blobs from linux-libre is because of a limitation of the deblobbing process. From [0]: Indeed, I became aware that some users have got the idea that blocking the loading of blobs is a feature. It's not; it's just a bug that's quite difficult to fix. The decision on whether or not to use a piece of software, be it Free or not, should belong to the users, and it's not our intent to make that difficult. If you can make the deblobbing script leave an escape hatch for users to load their own blobs, at their option, I'm sure the pull request would be well-received. [0] https://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-libre-interview-by-bruce-byfield.en.html https://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-lib...

detaro 5y ago
Then why is the reasoning in the linked email given as > Another significant change in this release is that it was pointed out that there were error messages in Linux suggesting users to update x86 CPU microcode. Since such microcode is non-Free Software, such messages don't belong in GNU Linux-libre. That reads very much as "we don't want to encourage users to consider updating microcode". Your argument also seems unlikely since distros ship the microcode as an extra package that gets picked up by the kernel, so clearly the ability to not upload microcode if the user doesn't provide it is there. (It makes sense that is that way and a different situation than the drivers your link discusses, since the device runs without a microcode update, whereas peripherals that need blobs often won't run at all without them)
marcan_42 5y ago
The deblobbing script includes an explicit section that censors the microcode update messages. http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3-gnu/deblob-5.15 http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3... Grep for "Do no recommend non-Free microcode update" [sic]. The actual censoring patterns are here: http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3-gnu/deblob-check http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3... Grep for "arch/x86/kernel/apic/apic.c" to find some of them.

by mbakke 5y ago

detaro 5y ago

Then why is the reasoning in the linked email given as > Another significant change in this release is that it was pointed out that there were error messages in Linux suggesting users to update x86 CPU microcode. Since such microcode is non-Free Software, such messages don't belong in GNU Linux-libre. That reads very much as "we don't want to encourage users to consider updating microcode". Your argument also seems unlikely since distros ship the microcode as an extra package that gets picked up by the kernel, so clearly the ability to not upload microcode if the user doesn't provide it is there. (It makes sense that is that way and a different situation than the drivers your link discusses, since the device runs without a microcode update, whereas peripherals that need blobs often won't run at all without them)

marcan_42 5y ago

The deblobbing script includes an explicit section that censors the microcode update messages. http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3-gnu/deblob-5.15 http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3... Grep for "Do no recommend non-Free microcode update" [sic]. The actual censoring patterns are here: http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3-gnu/deblob-check http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3... Grep for "arch/x86/kernel/apic/apic.c" to find some of them.