It does. They obscure the usage of non-free hardware/firmware by not shipping it as part of the OS, but as a bundle on separate flash storage that is loaded into the OS by initrd. That blob is updatable as "firmware". The 100% free open-source is just marketing. It's just for the OS. A lot of the hardware and firmware is proprietary.
It's basically taking the blobs that would be normally shipped with the OS in a sensible manner, shuffle it around, then calling it "free" while the same blobs would still be there, just on different flash storage chips.
Because it's true, and I know what he said, I am not confused at all. Did you not read anything at all?
On the Librem laptop, the tampering is done by PureBoot and inject into /run/firmware. The other user was linking the stuff with the laptop.
*On a Librem 5, it is stored on a separate chip, then they read it with the initramfs, then mount it on top of the regular filesystem at /lib/firmware*.
For the record, the "jail" only exists so PureOS (or any other distro) does not have to distribute any blobs within its repositories or include them in their images - though distros still can if they choose to, like postmarketOS does for example. There's very little difference between a firmware blob that's stored in a peripheral's internal flash, NOR flash or OS rootfs when it comes to user freedom, in the end it gets executed the same way on the same hardware. Having a separate place for these blobs only simplifies their management and allows to put a clear distinction of what's free and what's not. The important thing is that, regardless of whether the "jail" is used or not, there's not a single blob that runs on the user's CPU within the user's system on the Librem 5, which isn't a unique property for a phone but rare nevertheless; the peripherals are a different thing and Purism has never claimed that there are no blobs there (in fact, the existence of e.g. the DDRC blob was being highlighted already in very early development).
(also, the NOR flash itself already had to be there because that's what TPS65982 boots from, so the "jail" is just using the 4MB storage that would otherwise remain mostly empty)
I'm tired of arguing with you. I see no effort from your side to come to some understanding or to clarify anything. Here's why.
> On the Librem laptop, the tampering is done by PureBoot
What do you mean by "tampering" here? Is uploading firmware to peripherals a "tampering"? Why is this a problem, compared with other devices? Does anybof those blobs run on the CPU? I don't understand what you are trying to say.
> If you don't know that the firmware for components/peripherals can either be
I do know. How is this relevant? I never denied that the device does have some proprietary blobs.
Depends where you draw the line. There is not a single non-free blob in the OS that runs there once the bootloader is up (unless you put some there by yourself, which you're of course free to do).
I think you misunderstand what the Purism Firmware Jail is. I don't blame you though. They seem to make it purposefully misleading. It doesn't isolate what runs in the OS. It just isolates the OS updates from the non-free blob updates. The OS still runs the non-free blobs. It just loads it from separate flash.
It is you who is confused here. The first link is completely irrelevant to the Librem 5, and the second one points to a thread where the actual information present has been written by me.
The only non-free piece of code executed by the ARM Cortex-A53 cluster on the Librem 5 is the SoC's mask ROM bootloader. Once the control is passed to u-boot/ATF there is not a single non-free blob that runs there. Some peripherals may need blobs to be uploaded onto them to work, such as DP, DDRC and one of the used Wi-Fi cards (handled by ROM/u-boot/Linux respectively), while others boot from their own internal memories. Not all of those firmwares are non-free, but most are.
In the end, as I said earlier, the assessment depends on where you draw the line. I happen to draw it at the main CPU and the blobs that need to run within the user-controlled OS, which are unacceptable for me and which aren't present on the Librem 5.
Ah. I see. So the blobs are loaded into the separate microprocessors. Either way, it's the same as pretty much any modern phone, where the modem (and other secondary processors) are running some proprietary firmware and is communicating with the OS processor.
I don't see how it's different from running a free open-source ASOP OS. On the mainstream Android devices, the wireless hardware is also isolated and communication is done via IOMMU.
There's some debate as to whether using the USB stack for communication to the modem in the Librem 5 is less secure than IOMMU as well.
Pretty much any modern phone is also full of blobs that run on the main CPU to ensure basic functionality, with only a handful of exceptions. Just consider how many features stop working or get severely degraded on various phones when you use a clean AOSP build on them (provided that you can do it at all in the first place). Android's driver infrastructure effectively encourages non-free blobs in "vendor" partitions, and many things are purposely moved from the GPLv2 kernel to the userspace so they don't have to be copylefted. If you want to run a non-Android OS on these devices you either have to fill the gaps yourself or use these blobs through compatibility layers.
> at that point you still are trusting external communication to those devices with their proprietary blobs
Just as you do with any kind of peripheral, whether it implements what it's doing purely in hardware or with an embedded microcontroller.
> There's some debate as to whether the USB stack for communication to the modem is less secure than IOMMU as well.
You can have "some debate" on absolutely anything, but that doesn't yet mean it makes any sense. You have communication protocols on top of IOMMUs as well which are subject to exactly the same security considerations as potential exploits in the USB stack, so whatever debate you're referring to is unlikely to be held in good faith. I wonder why you mention it unprompted, as it's fairly off-topic here.
> Just consider how many features stop working or get severely degraded on various phones when you use a clean AOSP build on them.
That's mainly because of device trees. The firmware also isn't distributed via separate flash storage on the device, but I don't consider that making a difference. It's still proprietary firmware running on proprietary hardware. On Qualcomm-based Pixel devices, cellular, WiFi, Bluetooth, and GNSS are all isolated and sandboxed.
> It's also interesting that you mention it unprompted, as it's fairly off-topic here
A primary reason people complain about proprietary blobs is security. People claim that the Librem 5 is more open and secure, but it still uses the same proprietary modules as a Pixel running GrapheneOS. Does Librem 5 have signature checks for the firmware and a tamper-proof bootloader to load the firmware and OS, or can someone sell you a compromised Librem 5?
Is it more free, open, and secure than a Pixel running Android? Because, the only difference I'm seeing is how the firmware is stored and Google Play Services. And with GrapheneOS, only how the firmware is stored. Everything else points to a more insecure system with Librem 5.
> You can have "some debate" on absolutely anything, but that doesn't yet mean it makes any sense.
Sure, but from the fact that anything can be debated it does not follow that any given debate is nonsensical, which is kind of what you did there.
> ...whatever debate you're referring to is unlikely to be held in good faith.
I don't know which is odder, that assertion, or the notion that two completely different security models can't be debated in good faith because they're effectively identical, because of hand-wavy reasons like, "You have communication protocols on top of IOMMUs as well which are subject to exactly the same security considerations as potential exploits in the USB stack..."
Certainly there's some kind of argument to be made that the Librem 5 is relevant to this post as its adherents see it as a viable alternative to iOS and/or Android-based devices. I disagree, but everyone's willing to make different compromises and that's fair.
I only mention that because a contingent of voices as high in volume as they are few in number endlessly shoehorning the Librem 5 into numerous threads no matter how much of a non-sequitur it takes, has me suddenly paying more attention these days to what's coming from the Purism camp. The more I do the more disingenuous the rhetoric seems.
It may just be a coincidence, but for a project with such a fraught history and tarnished reputation, it doesn't do anything to increase my trust in it.
https://github.com/linuxboot/heads/blob/c859c28b88b7bc197c16...
https://forums.puri.sm/t/the-librem-5-blob-list/28815/26