Comment by marcan_42
4 years ago
> Librem 5
Ah yes, that phone where the FSF told them they had to move a blob from the bootloader into an external Flash memory and load it through two layers of CPUs, because going through that pointless dance magically makes it Free™ (read: hidden enough that users won't notice so they won't realize they're still running a blob as part of something as critical as making the RAM work).
Also that phone which runs a pile of other giant blobs, including the USB-PD controller and the baseband, of course.
The point is that the proprietary software has no access to the RAM or CPU and plays absolutely no role whatsoever in the device usage. I personally agree that it can be called "hardware" and don't care that it has another CPU.
The baseband is on the upgradable M.2 card, also has no access to anything. It can even be killed with a hardware switch. The best smartphone you can find if you care about it. Nobody says that other blobs are fine, but it's already a huge step to the freedom.
> The point is that the proprietary software has no access to the RAM or CPU and plays absolutely no role whatsoever in the device usage.
The proprietary software literally configures the RAM on the phone. It is critical for making the RAM work, of course it has access to the RAM! Supposedly it should be quiesced after training, but I haven't seen any security analysis that claims that firmware couldn't just take over the system while it runs.
But they added an extra two layers of indirection, even though the blob ends up running on the same CPU with the same privileges in the end anyway, because all that obfuscation let them get in via the FSF's "secondary processor" exception somehow. Even though the end result is the same, and you're still running a blob to perform a critical, security-relevant task.
If the goal is security ("blobs can't take over my system") and stuff running during the boot process doesn't count, then Apple's M1 machines are on precisely the same level as the Librem 5: they also run blobs on boot, and at runtime all remaining blobs on separate CPUs are sandboxed such that they can't take over the main RAM/CPU.
You are of course right that technically it has the access to the RAM.
> Supposedly it should be quiesced after training, but I haven't seen any security analysis that claims that firmware couldn't just take over the system while it runs.
I was under impression that it was the whole point of the exercise. It would be interesting to know otherwise.
> even though the blob ends up running on the same CPU with the same privileges in the end anyway
This is not how I understood it. The Librem 5 stores these binary blobs on a separate Winbond W25Q16JVUXIM TR SPI NOR Flash chip and it is executed by U-Boot on the separate Cortex-M4F core. From here: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque....
11 replies →