GNU Linux-libre 4.15-gnu Deblobs Two New Drivers, Drops More Upstream References

[phoronix]

Phoronix: GNU Linux-libre 4.15-gnu Deblobs Two New Drivers, Drops More Upstream References

Once again being punctual with their releases, the GNU Linux-libre volunteers managed to release the GNU Linux-libre 4.15-gnu kernel a short time after Linus Torvalds on Sunday released the official Linux 4.15 kernel...

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

[pal666]

i wonder, do those idiots deblob intel cpus from microcode meltdown fixes?

[planetguy]

i wonder, do those idiots deblob intel cpus from microcode meltdown fixes?

Among the things removed is MICROCODE_INTEL, so I think that's a yes.

[pal666]

and intel cpus continue to run same non-free software, just earlier vulnerable version...
fsf is run by lunatics

[WolfpackN64]

and intel cpus continue to run same non-free software, just earlier vulnerable version...
fsf is run by lunatics

GNU/Linux-Libre is in many ways a statement. It shows just how many proprietary blobs are needed to run a damm system, even though the few example of completely blob-free systems show it's possible. You can't blame the FSF for doing something ideologically, that's their thing. And who are you going to trust to carry the foss banner? The Linux Foundation?

I don't use GNU/Linux-Libre as a kernel, but at least I understand why it's there. You could have the decency by at least trying to understand before you call the good people at the FSF "lunatics".

[bridgman]

The line is still in the wrong place though... proprietary blobs executing from on-chip ROM are fine, while the same blobs executing from RAM are bad. The end result is that users end up having to flash BIOSes rather than update their software in order to use their CPUs properly.

Separately, hardware and system designers are sent a powerful message that hiding their microcode images in on-chip ROM or BIOS-loaded flash will get them support and praise from FSF, while delivering equally updateable microcode via easily removable files will result in their hardware support being stripped out of libre distros.

[R41N3R]

Linux-libre is a important project, it shows exactly where we need improvements. Without the fanatics we would just continue to trust closed blobs everywhere. We really need to replace as many blobs as possible to make CPU's trustworthy again. Especially if they are not required at all, like in the boot process the overly slow and fat UEFI. A small coreboot image would just works so much better.

Even if there is actually less Intel hardware that we can use for linux-libre, it is not the fault of this project. This is clearly Intel selling shit to us. It's not like we can trust the latest firmware either, it is known to crash several system. In this case free software kernel and gcc mitigations and bug fixes are so much more important than this Intel firmware anyway.

[Hibbelharry]

i wonder, do those idiots deblob intel cpus from microcode meltdown fixes?

Among the things removed is MICROCODE_INTEL, so I think that's a yes.

CPU ucode will still be there, loaded by the mainboard BIOS. You just hit the chance to have a less stable, less secure System and have bigger hurdles getting your system secured, by needing to flash a new bios.

Another funfact: If the ucode gets integrated into the Chips itself, any chip, by implementing a ROM into the package, nothing gets better. It will just be more inconvenient and foreseeably harder to get to know the exact function.

I understand why these people try to do that thing, but they will never win, they can't. Their solutions are proving shortsight thinking in such a devastating manner, that it's really fair to call them lunatics.

[bridgman]

Linux-libre is a important project, it shows exactly where we need improvements. Without the fanatics we would just continue to trust closed blobs everywhere. We really need to replace as many blobs as possible to make CPU's trustworthy again. Especially if they are not required at all, like in the boot process the overly slow and fat UEFI. A small coreboot image would just works so much better.

With respect, you are mixing platform firmware (running on the CPU) with hardware microcode (part of the CPU or other chip's HW design).

Agree that opening up platform firmware is going to be generally beneficial, but you can't automatically extend that to the microcode portions of a HW design by analogy.

The problem with "showing where we need improvements" is that the most common "improvement" that results is burning microcode into the chip rather than having it be loadable and upgradeable, which in turn makes things like Meltdown/Spectre fixes impossible.

[phoron]

The line is still in the wrong place though... proprietary blobs executing from on-chip ROM are fine, while the same blobs executing from RAM are bad. The end result is that users end up having to flash BIOSes rather than update their software in order to use their CPUs properly.

Separately, hardware and system designers are sent a powerful message that hiding their microcode images in on-chip ROM or BIOS-loaded flash will get them support and praise from FSF, while delivering equally updateable microcode via easily removable files will result in their hardware support being stripped out of libre distros.

This is also considered and there are reasons for it. You may not like them, but there exist.

The idea (which you might share) is that by using some vendors hadware you implicitly trust that vendor. There can be ROMs anywhere whether they tell you or not. In theory there might even be hardwired backdoors or threats without even code in ROMs. The difference between (a) ROM-only blobs and (b) uploadable blobs is that with (a) you trust the vendor once and with (b) you have to keep trusting them everyday in that they won't introduce new threats with updated blobs, either by malice, incompetence, government coercion or attack against the vendor. It's a little like secure boot, you make sure nobody can change some code. A ROM makes absolutely sure of no change (for good and for bad), while secure boot signature checks allows only signed changes (for good or for bad depending on whose keys they are, how securely hold and used, etc.).

Vendors don't generally like to put their firmware in a unchangeable ROM. They know they can make mistakes. If you encourage a vendor to use ROMs with blobs instead of uploaded BLOBs maybe they'll have to test better and make sure their blobs work. Their other option is providing uploadable free code, which the FSF would clap at. So they are really encouraging vendors to free firmware. Not that I think they're in a position to have a large impact, but anyway.

The advantage of having uploadable BLOBs instead of BLOBs in ROM is:

1- if you trust the vendor, you can get their fixes.

2- if you don't, you can reverse engineer the BLOB and provide a free alternative for it.

2 is unlikely due to lack of information about the hardware, short hardware lifespan and small available workforce, but it may depend on each case. 1 is not something to expect from FSF (they don't trust proprietary software providers).

So yes, in a first order approach there is a contradiction. If you don't trust a vendor you shouldn't use their hardware (or firmware). If you trust them you can as well trust their updates to propietary firmware.

But you can look at some finer grain: if you don't trust the vendor but can't find a vendor you trust (all free firmware), then your options are no hardware at all or trying to trust the vendor as little as you can (only once, when you buy the hardware). Hence the blobs in ROM as a lesser evil.

One possibily advantage of the linux-libre approach is poiting out what BLOBs are there and what they do. That helps selecting hardware.

But if you don't share FSF ideas, don't expect to like their recommendations. If you share them, don't expect all others to share them (yet?). If they don't, don't expect FSF to be able to fix the world (yet?).

Edit to add: I realise the way I wrote it, it sounds like "trust" is about security. It does not have to be that only. You may not want to use proprietary software for ethical reasons, because you feel ripped when you buy software and only get part of it, the binary, the proprietary terms of use make the bargain unattactive or educational reasons or whatever, you could change "trust" by "like" or something. The point is more or less the same.