GNU Linux-libre 5.13-gnu Released For The Latest Kernel Deblobbing

[Filiprino]

One day firmwares will be libre, too.

[phoron]

You can't both call yourself a protector of user freedom AND remove capabilities from the user. It's a fundamental betrayal of of the zeroth freedom of free software.

Mmm.. Apparently you hadn't vented enough.
I guess you also find those adverts against drugs "Just say no" to be utterly authoritarian and fascist or something.

All of what the vanilla kernel does is plain for everyone to see, both in the code and by reading the fucking manual. Unlike Linux-Libre, it doesn't strip anyone of any freedoms of what they may or may not physically accomplish. Again, back to Freedom 0.

code

advertisement:

MODULE_LICENSE("GPL v2");

And clock multiplier locks.

Really ? I don't think we live in the same world if you think overclocking is the same kind of concern as proprietary code.

[skeevy420]

It's funny that recently Apple Computer, often the target of free software advocates, was in the news for arguing that locking iPhones to Apple's curated App Store was good for the consumer and somehow gave them more choice (?!?). Now we see an example of their supposed ideological opposites also arguing that preventing you from running software they don't approve of is somehow in your best interests and making your life better.

I saw that and I actually agree with Apple to some extent. Most people buy those devices to have locked down, consistent, catered, and curtailed experiences with privacy and security in mind. If I had to give reasons to like Apple and their devices, that would be it.

You buy Android and it's basically the Wild West from one phone or tablet to the next in regards to App Stores, hardware functionality, updates, software features, privacy, security, etc. You buy Apple and you basically know what you're getting and how long you're getting it for while feeling safe using it. I don't like the closed down nature of it, but I get the appeal.

Frankly, I consider it an informed consumer choice to buy a locked down system that tries to offer more privacy and comes from a Computer Company versus buying the opened up system that lets you do whatever and comes from the Advertising Company.

Eventually we'll have the choice of buying an opened up system from an Open Source Computer Company. I know I'm not the only one keeping an eye on Pinephones, etc. I'm really tired of using software made by the Advertising Company that makes me feel like I'm being spied upon. Posted from Windows 11 that's probably keylogging this entire post

[hotaru]

I concluded that Linux-libre was a dead-end years ago when they refused to stop removing an interface that would have allowed users to load open source firmware that was developed by reverse engineering the hardware, because they cared more about preventing people from using the original closed source firmware than about allowing people to use the new open source firmware.

I hope that anyone running Linux-libre is at least responsible enough to keep their vulnerable outdated firmware off the internet.

[chocolate]

It's not the use case. It's the stripping of user freedoms by Linux-Libre. Plain and simple.

You seem to judge Linux-libre for somehow removing choice (not software freedom) as if choosing Linux-libre for what it is weren't by itself a valid choice as well.

[Developer12]

Man you write a lot of garbage. There is nothing in Linux Libre that stops you installing BLOBs if you want to: it just doesn't ship them by default. Just compile the modules you want (if necessary), drop in the firmware files, and off you go.

Linux Libre explicitly strips without the ability to load firmware or microcode. That capability is gone. It even, as noted above with a mailing list link in the attached tweet, strips out warning messages about vulnerabilities which require (now un-loadable) microcode to fix.

Repeated, for your convenience: https://twitter.com/mjg59/status/1377402589386432512

Alternatively, maybe people who are actually interested in this stuff explicitly buy hardware that already has fully open firmware anyway? Just like some people only buy AMD/Intel GPUs for Open Source driver support.

If it has fully open firmware, why install Linux Libre at all?

Why do you want to deny people the ability to see which bits of Linux work without the hardware blobs? Does it hurt you personally in some way?

Maybe people could actually look it up? It's not like you have that many devices in your computer.

The alternative you're suggesting is just to "install it anyway" and find out what breaks (or what they're unprotected from) the hard way.

[Developer12]

You seem to judge Linux-libre for somehow removing choice (not software freedom) as if choosing Linux-libre for what it is weren't by itself a valid choice as well.

People are free to run whatever they like (except firmware and security patches, if they're running Linux-Libre apparently).

The problem I and other commentators have with Linux Libre (and a sadly growing contingent of free software, see my first post) is the level of comfort they have with the moral superiority of stripping rights from their users. [1] is one such example of Linux Libre's developers stepping boldly over the line into user harm by stripping out legitimate warnings of insecurity (which might otherwise hurt the brand image of their product).

This (and other) pyrrhic scarifies of their user base have erased any trust I might have ever had in their judgement and product.

[1] https://twitter.com/mjg59/status/1377402589386432512

[phoron]

they refused to stop removing an interface that would have allowed users to load open source firmware that was developed by reverse engineering the hardware, because they cared more about preventing people from using the original closed source firmware than about allowing people to use the new open source firmware.

This sounds like valid criticism. Do you have a link to learn more ?
I suppose it was more lack of manpower to find a good solution that allowed both (possibly needing to integrate the firmware upstream or something, and kernel.org not willing to do it in some way that allows linux-libre to keep the free firmware and block the proprietary firmware). But I don't know the case.

[phoron]

[1] is one such example of Linux Libre's developers stepping boldly over the line into user harm by stripping out legitimate warnings of insecurity (which might otherwise hurt the brand image of their product).

[1] https://twitter.com/mjg59/status/1377402589386432512

Sorry I don't feel like reading twitter.
Anyway I can guess they can't know whether the patch fixes a bug or introduces one, whether it fixes one vulnerability and introduces others, etc. The warning is taking for good the word of the manufacturer that installing the new firmware is better than not. And that should maybe be said by the manufacturer, not by linux-libre who hasn't got any way to check whether it's true. They could at most say "that vendor says their previous firmware has a vulnerability and a new version fixes it which might or might not be true, but what we know for certain is that the firmware is not free so we're not loading it". Hardware vendors should step up their QA before shipping or open their firmware. They're simply shoving more functionality into proprietary software and having third parties work as their distribution channel for free when they screw up.

[Developer12]

Sorry I don't feel like reading twitter.

I'll save you the trouble then. To quote Matthew Garrett:
Again reminded of https://lists.gnu.org/archive/html/info-gnu/2018-04/msg00002.html, in which a GNU project [linux libre] removes a warning message informing users that their CPU microcode leaves them vulnerable to CPU microarchitectural attacks
Now, yes, the world would be a better place if we didn't have to rely on fairly opaque non-free code for our CPUs to work. But refusing to inform users of the tradeoff they're making in staying with old insecure microcode is not to their benefit.
Endquote.

Anyway I can guess they can't know whether the patch fixes a bug or introduces one, whether it fixes one vulnerability and introduces others, etc. The warning is taking for good the word of the manufacturer that installing the new firmware is better than not. And that should maybe be said by the manufacturer, not by linux-libre who hasn't got any way to check whether it's true. They could at most say "that vendor says their previous firmware has a vulnerability and a new version fixes it which might or might not be true, but what we know for certain is that the firmware is not free so we're not loading it".

This is 100% false. Do some research. A summary is below.

These warnings are given by code which was added to the kernel to manage mitigations to hardware vulnerabilities. That's right, manage. Most of the time, even if it WAS possible to apply a singe patch and completely fix the problem, for many of these flaws the result would be an unacceptable drop in performance due to the carved out functionality. Instead, the patches typically implement a mechanism that is triggered by the kernel to interfere at the right moment.

One famous example is IBRS or Indirect Branch Restricted Speculation. This mechanism is a nasty, hacky microcode patch which when activated brings the CPU to a stunningly slow crawl. People VASTLY overestimate what microcode can do. However, it does successfully clear the branch predictor state, particularly on Skylake (and above) where retpolines didn't work properly before RSB stuffing was figured out. (Skylake falls back to the poisoned Branch Target Buffer if the Return Stack Buffer underflows) The correct (and intel-recommended) semantic is to engage IBRS when crossing certain privilege boundaries and then IMMEDIATELY turn it off again. The CPU has no idea a-priori when the right time is.

Now, how do we know any of this works like we think it does? The answer to that is stupidly simple: people discovered it; people test it.

The original batch of CPU vulnerabilities were discovered outside of Intel by Google's Project Zero. They characterized the problem and developed proof of concept exploits. These were then tested against the mitigations Project Zero developed to verify that they worked. This includes the (incomplete) retpoline defense. [2] So far the overwhelming majority of the follow-on spectre exploits have been discovered by independent researchers and described in detail in research papers, complete with the steps require to exploit them. These descriptions and methods of exploit have in turn informed Intel and AMD's creation of microcode patches and the development of mitigations in the kernel community, for which microcode patches may or may not be mandatory. For a list of mitigated exploits, see [1]'s README. There's a lot, and that's just the ones that have found their way into the script. Intel released a patch a couple of weeks ago that disables a zero-fill optimization that saves DRAM bandwidth (and thus power) that someone found could be used to guess memory contents on Skylake and above.

Every step of the way, the proof of concept exploits described in the research papers have been tested against the mitigations developed. [3] Apply microcode patch and run a kernel that knows how to use it? Paper's exploit test fails. Don't do that? Test succeeds. Kernel devs don't add code to the kernel with significant performance impacts without proof that the threat exists AND that the mitigation works.

As for "but what if they added a ton more vulnerabilities":

Do you have any idea how small the patch RAM in a CPU is? They're called "patches" for a reason. The microcode *ROMS* are much, much larger and were baked into the CPU before it left the factory. You have been completely, inexorably dependent on nonfree microcode from the moment you first powered on your computer. People talk about microcode loading as if it's some kind of executable software you load, like into an empty wifi radio, and without which the radio is simply inert. This couldn't further from the truth. Microcode is written during the design of the CPU's internal structure, is inextricably tied to it, and is absolutely essential to it working *at all.* Applying a microcode patch after the fact to apply a tested fix to a known vulnerability hardly changes that. Likewise, not applying it does nothing to that complete and utter dependence. It's the price you pay for having bought and for using a CPU designed and made by someone else.

Aside:
To paraphrase another person's twitter, you'd think most people in free software had never taken a course on digital design after the 1970's. ROMs are somehow only used for harmless lookup tables, as if nobody started sprinkling concealed 8051 CPUs into everything. (just what do you think manages temperatures and power consumption in CPUs/Chipsets/GPUs? Calibrates PHYs on modern high-speed interconnects like PCIe?)

This is even reflected in the RYF certification in the form of a carve-out for ROMs, so long as the user can't alter them. (After all, why create a panic over USB mice and keyboards, the Lenovo-programmed Embedded Controller in Richard Stallman's thinkpad, or even his CPU's power management or factory-burned microcode? Yes. Richard Stallman is running MEGABYTES of proprietary code right now) Purism seals away their RAM-PHY-init blob (from Synopsys) in a secondary core where the user can never inspect/disable/replace it? Totally kosher. Leave the user open to replacing it with a future free alternative? No RYF certification for you. It's ass-backwards, and again isn't to *any* user's benefit.

[1] https://github.com/speed47/spectre-meltdown-checker

[2] Repoline is sufficient for protecting the kernel, but not userspace. All software must be modified and recompiled with it to receive protection, and most have not been. Instead, the more comprehensive defense is to poke IBPB (Indirect Branch Prediction Barrier, added by a suitable microcode patch) during context switches.

[3] It's worth noting that in at least one case, the kernel devs have preferred their own mitigation. Spectre v1 is officially supposed to be mitigated with expensive memory barriers (no microcode) but the kernel devs found a bit masking operation to be equally effective and less costly. This isn't always the case though, and for many later flaws only updated microcode is available as no software mitigation is possible due to the mechanism of the attack.