|
|
Log in / Subscribe / Register

Josefsson: Introducing the Debian Libre Live Images

[Posted November 17, 2025 by jzb]

Debian developer Simon Josefsson has announced the Debian Libre Live Images project, to allow installing Debian without any non-free software:

Since the 2022 decision on non-free firmware, the official images for bookworm and trixie contains non-free software.

The Debian Libre Live Images project provides Live ISO images for Intel/AMD-compatible 64-bit x86 CPUs (amd64) built without any non-free software, suitable for running and installing Debian. The images are similar to the Debian Live Images...

He does warn that this is a first public release, so there may be problems. See the current list of known issues before trying the images out.


to post comments

Great news

Posted Nov 18, 2025 16:23 UTC (Tue) by IanKelling (subscriber, #89418) [Link]

I hope these start getting created as part of Debian itself at some point again.

Consistency?

Posted Nov 19, 2025 18:56 UTC (Wed) by Vorpal (guest, #136011) [Link] (11 responses)

I don't get why there seem to be some people who are OK with non-free software on their computers, but only if it isn't loaded via Linux. Because that is what this is effectively. Even if you use coreboot, there is still some blobs from AMD or Intel. And there is still some proprietary software in your SSD controller. And many devices come with default firmware on them: NICs, GPUs, laptop charge controllers, thunderbolt controller, etc.

Sure, I would love for it to all be open. But unless you breadboard your own 16 bit computer from basic logic chips, that is not feasible today. (Yes Power9 was pretty open, still had ssd/hdd controllers though.)

So why does it make a difference if you load / update the firmware from the main OS, or if it is already there before?

Consistency?

Posted Nov 19, 2025 19:51 UTC (Wed) by donbarry (guest, #10485) [Link] (4 responses)

This is a criticism that has been directed at the Free Software movement again and again, but at it's heart it boils down to "I'd rather trade temporary convenience for permanent freedom."

Setting a standard is setting a goal: to make anything we actually *can* change on hardware we possess free, short of getting out a soldering iron and practicing electrical engineering.

The history of computing has shown that when we stop setting these goals and slouch away from software freedom, we end up with locked-down platforms, like most of those that run Android, where it is difficult or impossible to enjoy the benefits that come from software freedom.

Consistency?

Posted Nov 19, 2025 20:03 UTC (Wed) by pizza (subscriber, #46) [Link]

> The history of computing has shown that when we stop setting these goals and slouch away from software freedom, we end up with locked-down platforms

Sure, but that doesn't change the poster's point, namely: "So why does it make a difference if you load / update the firmware from the main OS, or if it is already there before?"

(And if your goal is to make anything we *can* change to be free, why is it somehow preferable to make things unchangeable instead of making things that can be eventually changed to be free?)

Consistency?

Posted Nov 19, 2025 21:51 UTC (Wed) by hailfinger (subscriber, #76962) [Link]

> This is a criticism that has been directed at the Free Software movement again and again, but at it's heart it boils down to "I'd rather trade temporary convenience for permanent freedom."

Sorry, the original poster didn't say that. The original poster pointed out the hypocrisy in this approach. Load microcode into the CPU? Sure, as long as it's the BIOS/UEFI/whatever doing it and not Debian-derivative, so this specific Debian-derivative can stay "pure". Load other firmware into peripherals? Sure, as long as it's not Debian-derivative doing the loading.

If a religion calls for one layer of indirection ("don't do evil thing XY, rely on someone else to do the evil thing on your behalf"), then sure, this Debian derivative is the solution.

If one layer of indirection were intellectually and ethically sound, then the Nvidia binary only GPU driver crowd would have been right all the time by re-using this style of argument with "it's the user and not Nvidia compiling the abstraction layer, there is no licensing problem". For the record, I disagree with such an interpretation.

Consistency?

Posted Nov 20, 2025 9:34 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

This is a criticism that has been directed at the Free Software movement again and again, but at it's heart it boils down to "I'd rather trade temporary convenience for permanent freedom."

Exactly - why does the FSF advocate (via the RYF program) for locked-down, DRM'd binary blobs in the name of convenience, when it could advocate for permanent freedom?

Consistency?

Posted Nov 21, 2025 2:26 UTC (Fri) by pabs (subscriber, #43278) [Link]

I've got a suggestion for fixing RYF, but it hasn't been adopted yet:

https://libreplanet.org/wiki/Group:Free_Software_Foundati...

Recently sent a mail to the FSF to get it on their radar again.

Consistency?

Posted Nov 19, 2025 21:33 UTC (Wed) by brunowolff (guest, #71160) [Link]

There are other people working to make this happen using a different approach, but it is going to take a long time. The tools to make chips at the logical design level are getting more open. Bunnie Huang gave a talk at Teardown 2025 about why he believes there is going to be an opportunity to affordably build chips at 28nm that aren't ridiculously behind the state of the art in capability. He also discussed some strategies for assuring that the chips that are built for you are actually what you ordered. This may be a more practical approach for getting from here to there, than what the FSF is trying for firmware/hardware.

Consistency?

Posted Nov 19, 2025 22:23 UTC (Wed) by brunowolff (guest, #71160) [Link] (4 responses)

External storage (HDD, SSD) is much less of a problem, because with proper use of encryption (which you want in any case), they are mainly relegated to DOS attacks. Other peripherals are more of a concern.

DMA attacks

Posted Nov 20, 2025 17:25 UTC (Thu) by DemiMarie (subscriber, #164188) [Link] (3 responses)

DMA attacks are a think, and the kernel drivers trust the devices so the IOMMU doesn't help here.

DMA attacks

Posted Nov 20, 2025 21:26 UTC (Thu) by brunowolff (guest, #71160) [Link]

Thanks. I had thought that things had changed is this regard and that DMA requests were well vetted these days, but apparently not.

DMA attacks

Posted Nov 21, 2025 9:07 UTC (Fri) by anton (subscriber, #25547) [Link] (1 responses)

the kernel drivers trust the devices so the IOMMU doesn't help here.
The conclusion is that the kernel should distrust the devices, in particular when it comes to DMA.

DMA attacks

Posted Nov 21, 2025 12:13 UTC (Fri) by pizza (subscriber, #46) [Link]

> The conclusion is that the kernel should distrust the devices, in particular when it comes to DMA.

That's nice in theory, but no amount of "kernel distrusiting the devices" matters when said device has full access to system memory and is free to ignore what Linux tells it to do.

Indeed, there are plenty of real-world systems out where Linux (and the application cores it runs on) are explicitly not in charge of setting up address translation units and bus-level "firewalls". Linux is in a totally subservient role on those systems.

It's like Debian, only less useful!

Posted Nov 19, 2025 23:20 UTC (Wed) by pizza (subscriber, #46) [Link] (10 responses)

> The Debian Libre Live Images project provides Live ISO images for Intel/AMD-compatible 64-bit x86 CPUs (amd64) built without any non-free software, suitable for running and installing Debian.

....It's like the regular Debian Live images, except it probably won't work with your hardware!

(And/or expose you to exploitable security vulnerabilities along the way)

It's like Debian, only less useful!

Posted Nov 19, 2025 23:54 UTC (Wed) by ballombe (subscriber, #9523) [Link] (9 responses)

Sure, installing firmware that cannot be audited is an excellent security posture.

It's like Debian, only less useful!

Posted Nov 20, 2025 0:20 UTC (Thu) by hailfinger (subscriber, #76962) [Link] (4 responses)

Having someone else install firmware that cannot be audited is even worse.

It's like Debian, only less useful!

Posted Nov 20, 2025 0:27 UTC (Thu) by pizza (subscriber, #46) [Link] (3 responses)

> Having someone else install firmware that cannot be audited is even worse.

If "someone else" has the necessary level of access [1] to your system to install firmware, you're already well past the point of being totally screwed.

[1] ie direct physical or remote superuser-level rights

It's like Debian, only less useful!

Posted Nov 20, 2025 11:48 UTC (Thu) by hailfinger (subscriber, #76962) [Link] (2 responses)

You're absolutely right about that. If "someone else" is an attacker with remote system-level access or direct hardware access, I wouldn't trust that machine anymore and consider it to be scrap metal (or a nice exercise for forensics).

Given that "install firmware" in this thread was mostly used in the sense of "uploading firmware to some component and having the component execute it", there is pretty much zero conceptual difference between BIOS/UEFI uploading ("installing") said firmware or Linux doing the same.

This "someone else" can be the BIOS/UEFI/coreboot, and yes, if you don't trust the supplier of that, you're screwed. As a side note, coreboot can be stripped down to not contain any binary blobs and you can also remove all the other blobs not loaded by coreboot, but you're then limited to an Intel Core 2 Duo (i.e. Thinkpad T400 from 2008). Totally valid choice, but somewhat limited in compute power. I still have a fully free corebooted Thinkpad T60 around for nostalgia reasons.

Now if "install firmware" means rewriting the firmware in some permanent storage (flash, whatever), stock Debian doesn't do that automatically, you manually have to run the respective updater. For this definition, having a Debian-derivative without such a permanent-storage-rewriting updater only make sense if you want to remove the ability of users to perform such an update. That would also result in denying them the ability to update to a free firmware replacement, should such a replacement ever appear. As a philosophical choice, that is totally OK if the philosophy says that users need to be protected from temptation.

It's like Debian, only less useful!

Posted Nov 21, 2025 10:02 UTC (Fri) by taladar (subscriber, #68407) [Link] (1 responses)

Install firmware could also mean a manufacturer installs it in some sort of permanent storage that can not be flashed (or can't be without hardware modifications at least).

It's like Debian, only less useful!

Posted Nov 21, 2025 12:10 UTC (Fri) by farnz (subscriber, #17727) [Link]

The danger is that the manufacturer promises that this is permanent storage that cannot be flashed, but it in fact can via a "backdoor" interface that you don't know about.

Or worse, the Prism2/3 firmware, where it was in permanent storage, but the firmware had a way (probably DRM'd nowadays), to upload new firmware at run time.

It's like Debian, only less useful!

Posted Nov 20, 2025 0:23 UTC (Thu) by pizza (subscriber, #46) [Link]

> Sure, installing firmware that cannot be audited is an excellent security posture.

Guess what's even more secure? Not being able to use the hardware at all! Except perhaps as a doorstop.

*EVERY* component of the system you used to write that message, from the keyboard to the motherboard (+processor) to the display to the storage devices to the networking adapter (and every intermediate system your data travels over), is already running proprietary, unauditable firmware. At best, disabling runtime loading of newer versions leaves you exposed to known security problems, crashes, and other bugs.

What "security" (or even "freedom") difference does it make if said firmware blob is physically stored under /lib/firmware versus stored directly on the device? If anything, having the firmware stored on the local filesystem is preferable because you can at least verify it hasn't been altered/replaced without your knowledge. It also gives you a path to one day replacing said firmware with a truly Free implementation, which I thought was the ultimate goal here.

It's like Debian, only less useful!

Posted Nov 20, 2025 2:17 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (2 responses)

Two choices here for devices that require firmware:

1) firmware is present in the device but can't be updated. In this case it is still as difficult (if not more so) to audit, but also any identified vulnerabilities can't be rectified. It is impossible to write free replacement firmware.
2) firmware is loaded at runtime and is, in most cases, easier to examine than something built into on-package ROM. Vulnerabilities (and other bugs) can be fixed by the manufacturer. Depending on design, it may be easier to replace with free firmware.

I don't see why (1) is obviously better for security.

It's like Debian, only less useful!

Posted Nov 21, 2025 2:30 UTC (Fri) by pabs (subscriber, #43278) [Link]

There is also:

3) firmware is present in the device and can be updated (using a secret/NDAed protocol implemented in an proprietary/NDAed binary only the hardware OEM and their customers have access to). IIRC that was the situation with the OpenMoko WiFi chip, and the firmware was also notoriously buggy.

It's like Debian, only less useful!

Posted Nov 21, 2025 2:33 UTC (Fri) by pabs (subscriber, #43278) [Link]

2) has several subsets too, depending on the presence of signature verification and acceptance of new keys or published private keys. nvidia GPUs vs Intel Sound "Open" Firmware comes to mind here.

Libre firmware?

Posted Nov 21, 2025 2:36 UTC (Fri) by pabs (subscriber, #43278) [Link]

I wonder if these include any of the Libre firmware that exists?

https://wiki.debian.org/Firmware/Open


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds