GNU Linux-libre 6.2 Continues The De-Blobbing Battle

[phoronix]

Phoronix: GNU Linux-libre 6.2 Continues The De-Blobbing Battle

Building off yesterday's release of Linux 6.2, the GNU Linux-libre 6.2 kernel was published today by the GNU FSFLA folks maintaining this kernel downstream that strips out driver support dependent upon non-free software firmware/assets as well as dropping the ability to load closed-source kernel modules...

https://www.phoronix.com/news/GNU-Linux-Libre-6.2

[andyprough]

introduced a brand new old-fashioned sourceless binary blob disguised as a sequence of numbers, i.e. binary object code encoded as pseudo-sources

That's rather unfortunate. Too bad Linus and the kernel maintainers are allowing such things to pass through. I'm still using the 4.19 and 5.10 LTS versions, so this will have 0 impact on me. But still, it's the principle of the thing.

By the way, happy 15th birthday to Linux-libre! Here's the announcement for the original 2.6.24 kernel from 2008: https://web.archive.org/web/20221001...7ba592.en.html
Unfortunately, Linus was allowing Broadcom and others to toss their non-free nonsense into the kernel back then, and Linux-libre originator Jeff Moe had the receipts:

The official "vanilla" Linux kernel from Linus that gets distributed on
kernel.org has non-free[1] software in it. Here is one example from
linux-2.6.24/drivers/net/tg3.c:


/*
* tg3.c: Broadcom Tigon3 ethernet driver.
*
* Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem@???)
* Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgarzik@???)
* Copyright (C) 2004 Sun Microsystems Inc.
* Copyright (C) 2005-2007 Broadcom Corporation.
*
* Firmware is:
* Derived from proprietary unpublished source code,
* Copyright (C) 2000-2003 Broadcom Corporation.
*
* Permission is hereby granted for the distribution of this firmware
* data in hexadecimal or equivalent format, provided this copyright
* notice is accompanying it.
*/


It then has screenfulls of non-free code like this:

0x0e000003, 0x00000000, 0x08001b24, 0x00000000, 0x10000003, 0x00000000,
0x0000000d, 0x0000000d, 0x3c1d0800, 0x37bd4000, 0x03a0f021, 0x3c100800,
0x26100000, 0x0e000010, 0x00000000, 0x0000000d, 0x27bdffe0, 0x3c04fefe,
0xafbf0018, 0x0e0005d8, 0x34840002, 0x0e000668, 0x00000000, 0x3c030800, [etc etc etc]

[Developer12]

One of the most pointless projects ever. Nobody tell them about all the firmware that's bakedinto the hardware itself. Oh wait, for some reason "ROMs" are 100% stallman approved.

[andyprough]

One of the most pointless projects ever.

What is pointless about knowing what the kernel is doing? That's a nonsensical statement. You may not always want to run a libre kernel, but you can't argue that there's never any point to it.

Nobody tell them

Tell who?

about all the firmware that's bakedinto the hardware itself.

Shocking. You are way out in front of everyone else, give yourself a pat on the back.

Oh wait, for some reason "ROMs" are 100% stallman approved.

Why do you conflate "unavoidable" with "desirable"? No one desires to have non-free firmware. Stallman and many others have noted that this is a concession to reality, otherwise you would not have nearly any running equipment.

[ALRBP]

One of the most pointless projects ever. Nobody tell them about all the firmware that's bakedinto the hardware itself. Oh wait, for some reason "ROMs" are 100% stallman approved.

What is pointless is your comment.

[skeevy420]

One of the most pointless projects ever. Nobody tell them about all the firmware that's bakedinto the hardware itself. Oh wait, for some reason "ROMs" are 100% stallman approved.

There's a really big difference between firmware that's baked into hardware that the user can never change, essentially making it fixed hardware, versus firmware that's loaded at runtime and/or can be updated by the manufacturer to do fuck knows what.

[oiaohm]

There's a really big difference between firmware that's baked into hardware that the user can never change, essentially making it fixed hardware, versus firmware that's loaded at runtime and/or can be updated by the manufacturer to do fuck knows what.

Its more complex than that. There is not the black and white divide.

1) Firmware embedded in device on rom
2) firmware embedded in device with update eeprom..
3) Firmware embedded in device replaceable at runtime.(this include cpu microcode)
4) Firmware on device being only a loader and device does not work without being sent firmware.

Type 4 for particular devices like radio devices can be very good so that if device is no longer legal to use you can delete the firmware file or driver and the device is dead.

Type 1 2 and 3 you can have the problem that the device is firing up on boot up. Now if this is part of your computer motherboard it could be now stop using your complete computer to be legal.

What about writable eeprom on devices. So even if the firmware is on the device and the OS does not need to load the firmware it still possible that manufacturer could have way of updating the devices firmware this is what https://fwupd.org/ Linux vendor firmware service is about.

Firmware in rom as fairly much died out because Manufacturers are normally bad at coding firmware and you will need to update it at some point to fix their defective code. Option 2 eeprom solution has come less popular due to end users updating their firmware and bricking their hardware. Option 3 and 4 are ram options that don't wear out quickly or at least not inside the useful life of the product.

https://www.kernel.org/doc/html/v6.2/driver-api/firmware/index.html

The big thing I have issue with. Is the Linux kernel has official firmware handling functionality. If you find blob of executable code in Linux kernel source code there is a big problem this is not using the Linux kernel API/ABI for firmware. Linux kernel drivers built right stopping the Linux kernel from loading binary blobs into hardware should be simply depopulate the firmware locations defined in the firmware API section of the Linux kernel. I am not saying those doing Linux-libre are not finding these issues but they should be opening upstream bugs if there is firmware blob in the Linux kernel source code.

Back in the early days of Linux the formal firmware API did not exist so parties put blobs inside the main Linux kernel source that was technically breach of the GPLv2.0 license and is still technically a breach todo.

[CommunityMember]

There's a really big difference between firmware that's baked into hardware that the user can never change, essentially making it fixed hardware, versus firmware that's loaded at runtime and/or can be updated by the manufacturer to do fuck knows what.

Because one you can't audit, and the other you can't audit either? The difference was only about accepting the reality.

[EphemeralEft]

God damn blobs ruining our kernel. The only thing I hate more than a blob is a bug. We should get rid of them all.

[onlyLinuxLuvUBack]

God damn blobs ruining our kernel. The only thing I hate more than a blob is a bug. We should get rid of them all.

how do you feel about systemd_blob ?