3 ms·

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 pres

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.

kuhsaft 6mo ago
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.
- seba_dos1 6mo ago
  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.
  - kuhsaft 6mo ago
    > 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.
    - seba_dos1 6mo ago
      > That's mainly because of device trees. Huh? The device tree is the one thing trivially recoverable from the blob. I'm talking about drivers, the same kind as when you install, let's say, the non-free Nvidia driver on a PC. They run as part of the OS and handle various stuff, most commonly comms like VoLTE/VoWiFi, but often also camera ISPs, GPUs, fingerprint readers etc. > are all isolated and sandboxed So isolated that you can break them by repartitioning your eMMC/UFS. > A primary reason people complain about proprietary blobs is security. The primary reason I care about blobs is freedom and practical aspects that come out of it. Dealing with blobs is always a PITA and severely limits what you can do with the hardware. The peripherals would be nice to have freed, but it's the main CPU and storage that is supposed to be my (the user's) domain and only mine. My Librem 5 came with a GNU/Linux distro on it, but if I wanted to port, say, FreeBSD to it there's all I need to be able to it. I can't do that with an AOSP device fed with blobs from the "vendor" image, at least not without spending years on reverse engineering. The Librem 5 is one of the handful phones out there that make it this easy. It is also the only one I'm aware about that's still being sold where you have the hardware ECAD and MCAD designs available - and not just to look at, but published on a free license. I think it has earned its bragging rights when it comes to freedom and openness. > can someone sell you a compromised Librem 5? Of course, just like any other PC. You want to reflash it before use, obviously. The SoC supports High Assurance Boot, you can burn your key into its efuses and have it only ever accept software that's cryptographically signed by you.

kuhsaft 6mo ago

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.

seba_dos1 6mo ago
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.
- kuhsaft 6mo ago
  > 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.
  - seba_dos1 6mo ago
    > That's mainly because of device trees. Huh? The device tree is the one thing trivially recoverable from the blob. I'm talking about drivers, the same kind as when you install, let's say, the non-free Nvidia driver on a PC. They run as part of the OS and handle various stuff, most commonly comms like VoLTE/VoWiFi, but often also camera ISPs, GPUs, fingerprint readers etc. > are all isolated and sandboxed So isolated that you can break them by repartitioning your eMMC/UFS. > A primary reason people complain about proprietary blobs is security. The primary reason I care about blobs is freedom and practical aspects that come out of it. Dealing with blobs is always a PITA and severely limits what you can do with the hardware. The peripherals would be nice to have freed, but it's the main CPU and storage that is supposed to be my (the user's) domain and only mine. My Librem 5 came with a GNU/Linux distro on it, but if I wanted to port, say, FreeBSD to it there's all I need to be able to it. I can't do that with an AOSP device fed with blobs from the "vendor" image, at least not without spending years on reverse engineering. The Librem 5 is one of the handful phones out there that make it this easy. It is also the only one I'm aware about that's still being sold where you have the hardware ECAD and MCAD designs available - and not just to look at, but published on a free license. I think it has earned its bragging rights when it comes to freedom and openness. > can someone sell you a compromised Librem 5? Of course, just like any other PC. You want to reflash it before use, obviously. The SoC supports High Assurance Boot, you can burn your key into its efuses and have it only ever accept software that's cryptographically signed by you.