GNU Linux-Libre 4.2 Takes Aim At AMDGPU & Intel's DRM Drivers

[IsacDaavid]

Is there a list of the hardware that the Libre kernel fully supports?

https://www.h-node.org/

If I understand this correctly, GNU Linux-libre removes all binary blobs from the kernel, including those which run exclusively on the hardware.

I can understand folks not wanting binary blobs running on the host CPU, whether they be in user level code or in the kernel.

But blobs which run exclusively on the hardware - such as the microcode for my AMD GPU - essentially have nothing to do with the host CPU. Such blobs are no different from the firmware running on the embedded ARM CPU in my Samsung SSD.

IMHO such blobs are part of the hardware design. It is not obvious whether GNU Linux-libre is trying to promote open source hardware too.

Software is software no matter what processor or microcontroller it runs on. Many of the peripherals have full DMA and are a security threat.
There's nothing the kernel can do about proprietary firmware which is already present in your SSD, but it can avoid loading blobs to other peripherals that expect the kernel to intervene, such as GPUs and WiFi chips.
You are confused about the analogy between firmware and hardware design. non-erasable firmware is what the FSF considers to be equivalent to hardware, which is not to say that hardware or non-erasable firmware can't be malicious. Reprogrammable firmware is still considered software

[tegs]

you think so, but linux-libre fanatics do not

They aren't fanatics. They are one of the last groups who actually care that you can use the hardware you bought or the software you install without having restrictions and to be locked out of it. I'm not talking just about source code, but using it without having to pay fees due to an imposed license. Oh and making sure that the hardware and software isn't infringing on your privacy.

I'm just surprised that you aren't happy having options. Its nice to be able to install an OS and use your hardware knowing you are safe.

[Nobu]

Signatures aren't perfect--you could inject code into a blob that kept the signature intact if you knew what you were doing. They are a good preventive measure, though.

[mdias]

Signatures aren't perfect--you could inject code into a blob that kept the signature intact if you knew what you were doing. They are a good preventive measure, though.

You got me interested. Got any material on the subject to share with us?

[Nobu]

Not exactly what I was talking about, but... https://www.redteam-pentesting.de/en...gnature-bypass (search "signed").

What I was talking about, though, was modifying the binary and keeping the signature intact. If you know what kind of key they used and can crack it, you can modify the binary in various ways while still returning the same "signature". Of course, this gets more difficult as the size of the key is increased, since the signature becomes more "detailed". I think there are ways to make cracking the key difficult or (nearly) impossible, but I don't know much about encryption itself so I couldn't tell you.

[Svartalf]

It's about the entropy present with the signature. More bits means harder to fake out because it becomes harder to make a signature collision, which is how you arrive at a forged binary.

[blackiwid]

But the real question that always comes up is this:

Before we had firmware blobs that had to be loaded with the kernel, we had upgradable firmware flashed into eeprom on the cards. That firmware could do everything that the current blobs can do, and it could still be reprogrammed for nefarious purposes, and it was still a black box as far as the operating system was concerned. The loadable firmware we use today is just easier to upgrade if bugs are found... How is that actually a step back?

I think the problem is that nobody would have forced u to upgrade the eeprom so the source of the kernel would have worked with the old version forever, so u can ignore the ability or its only a option, now the hardware vendors can force u to upgrade the proprietary bits. So u can not longer use it as it would been fixed hardware.

and with newer knowledge of spyware in firmwares as example of harddisks and network cards that were found in short or long we have to talk about going even a step further and demand the source of all this firmwares.

but for a step between it would be nice if computers still boot if no blob is loaded (intel).

[smitty3268]

I think the problem is that nobody would have forced u to upgrade the eeprom so the source of the kernel would have worked with the old version forever, so u can ignore the ability or its only a option, now the hardware vendors can force u to upgrade the proprietary bits. So u can not longer use it as it would been fixed hardware.

I'm not sure I follow. You're saying that someone will update the OSS code in the linux kernel to require newer firmware? And that's the bit you don't like? Couldn't you just fork the old kernel code and use it forever?

[bridgman]

AFAICS the perceived risk here is that vendors will "force" users to pick up evil new HW microcode by providing free support for driver code using that new microcode but not for drivers using the old microcode, or by fixing bugs in new microcode while simultaneously introducing something bad for users, and that building microcode into the chips avoids that risk by preventing vendors from making changes...

<SARCASTIC> Built-in microcode could never be evil, of course, and we always trust vendors who build microcode into the chip because it is convenient to do so. If we didn't arbitrarily trust vendors who used built-in microcode then we couldn't buy *any* hardware with a clear conscience and then where would we be ? </SARCASTIC>

Increased attack surface is a real issue (and IMO the only valid one), but that can be handled through firmware signing (whether done in driver code or in HW) and I think you will agree that the lowest risk is at the two ends of the spectrum - giving out zero information and giving out full source plus toolchains to build as part of every install. Anything in between is higher risk AFAICS. Given that even microcode-with-source tends to get pre-built and distributed as unsigned binary packages I still have a tough time seeing how providing source reduces the attack surface in real life though.

[blackiwid]

Built-in microcode could never be evil, of course, and we always trust vendors in that scenario because it is convenient to do so. If we didn't arbitrarily trust vendors who used built-in microcode then we couldn't buy any hardware with a clear conscience and then where would we be ?

First of all we could if we find there problems fix it outside that firmware and then for good. at least if its no process 0 thing like in the boot process so there this would be not enough, therefor we need a libreboot system to be secure.

And to trust the companies is to much to ask these days, even if I would belive that AMD as example has no intention to spy on their users or use other antifeatures, this companies have to comply to US law more or less and there are laws that allow the government to force them to buildin backdoors or security holes, and they can also make them lie about it.

Maybe for banks the bigger problems are criminals but for normal people and even for normal companies, spy agencies are the biggest problem, because they have more power and more money to do that, and the NSA as example officialy does spy on business.