cpu_rec:
https://github.com/airbus-seclab/cpu_rec> However, you seem to be unfairly criticizing Purism for obfuscation and legalisms, when it seems to me that Purism is just trying to comply with the FSF's rather arbitrary RYF rules
The question is why are they doing that? Why are they pandering to a program which ends up encouraging less free devices? RYF is completely broken and does not deliver what people think it does, and the FSF have shown zero interest in educating users about what it means and doesn't. It is a feel-good program that actually hurts the ecosystem behind the scenes. Why is Purism lending it legitimacy by attempting to get certification?
They should've done what bunnie did after Stallman showed up with that crazy "fuse the GPU off" idea: give up on this nonsense and focus on delivering a device as free as possible, instead of wasting engineering time pandering to a program that isn't helping anyone.
> It is not like Purism had any better options in terms of SoC's that it could have chosen for the Librem 5.
Indeed, and this is the crux of the problem: 100% libre modern hardware is impossible in the current world, but the FSF and people who buy in to their tactics keep pretending it is. That there is some magical line that denotes a device as "freedom-respecting" and they can just put things in that bucket and slap a sticker on it and sell it to all those freedom fanboys. This encourages further ignorance: users don't have to think about practicalities such as what security risks are actually present or what the lack of source code for some components might do to affect things they might practically want to do. They don't have to think about whether things are signed or validated, or how to verify that they are running software that is at the very least trusted to be a widely available build, or anything like that. They just see "no blobs in my filesystem!" "freedom!" and declare that device as a Friend of Free Software. And then they extrapolate from that a bunch of properties that are absolutely not implied, around privacy and security and more.
> It seems to me that Purism did the best that it could with an impossible situation, and if anybody should be criticized it is the FSF for not acknowledging how modern hardware actually works.
Purism did a decent job with the hardware; the RYF workaround development was completely unnecessary and just serves to legitimize the FSF, which, indeed, is the root of the problem.
> Another thing that I find problematic is your argument that 58 KB of DDR4 timer training blobs represent a security threat in the real world
Oh, they absolutely don't. In practice they don't; they also do not present any practical restriction on freedom. Even if the training code were open, I bet there isn't a single person who would ever modify it on a shipping device (especially one with soldered RAM). That's the kind of thing you need 6-figure test equipment to validate properly, and there is no reason to go mucking with it for any end user of the hardware. It existing as a blob causes zero reduction in practical freedom for users, because source code for it would only give you theoretical freedom that nobody wants or needs to exercise.
But you see, the entire FSF culture isn't about practicalities. That's the whole problem with it. It is about platonic ideals and philosophical arguments, and completely eschews looking at how real people are affected by software being open or closed. And from that point of view,
> and make the Librem 5 no different than an Apple device with an M1 processor
They indeed make it no different, because in both cases you're running blobs on boot, and you're in the same practical situation from an absolutist point of view, modulo the FSF's backdoor arguments.
> which is literally a black box.
How so? The i.MX8M is also a black box by that token; it's a pile of silicon. Sure, it may be (partially - those SoC programming manuals always have censored parts) documented, but it's not open hardware. You can't know what it does precisely. You can't prove the absence of a backdoor any more than you can with the M1.
> Forget the fact that the L5 is the first phone to have free/open source schematics
I have schematics for some of my M1 Macs. Sure, they leaked and were not willingly published... but in the end, I have them and can look things up in them. So for analysis/educational intents and purposes, I'm in a similar situation as you are with the L5.
(Of course it makes a difference in corporate goodwill that Purism published them deliberately; I'm just pointing out that you're limited to that aspect, since at the end of the day, we both have schematics for our devices, so we're both in the same situation as far as being able to understand them).
> and everything is running free/open source drivers.
We're working on that for the M1. You can run Linux on the M1 today with fully free/open source drivers for most critical parts of the hardware. This blog post has a table of hardware support and upstreaming status:
https://asahilinux.org/2021/12/progress-report-oct-nov-2021/
Looking up the Librem 5 devicetree in the upstream kernel, it seems it was submitted on Aug 21 2020. Aspen shipped in September 2019, so it took them about a year from shipping to upstreaming bring-up, and that's not considering internal prototypes and that the SoC was announced in mid 2018, so they had plenty of time to work on things internally.
I submitted upstream bring-up for the M1 Mac Mini with the device tree on Feb 4 2021, just 4 months after it was announced in Nov 2020. And that was working from scratch, on an unknown SoC, reverse engineering everything, having to make more intrusive patches to Linux because this SoC is quite "special", having to write our own pre-bootloader from scratch, etc. A year after release, we have a bunch more hardware working and on the way to upstreaming, including sound on the Mac Mini, I2C, SPI, NVMe, keyboard/trackpad on the laptops, USB and USB-C, power management, basic screen/display controller support, Wi-Fi (including on prior Macs going back to 2017), and support for 9 distinct hardware platforms including the just-launched M1 Pro and M1 Max models, which were already at feature parity a few weeks later. Given all that, I'd say we're doing a lot better with M1 upstream support with fully free drivers than Purism did, timeline-wise. And we didn't need a SoC programming manual. Maybe it's because we aren't wasting time trying to get RYF certification? :-)
Fun fact: the L5 and the M1 Macs use the same line of USB-PD controllers and share a driver, so it is very likely that some of our work on that front will benefit L5 users. The existing driver is very bare-bones and definitely needs more work.
> Think about how much code would be needed to initialize the cellular modem or WiFI and then run a TCP/IP stack to communicate with the outside world.
The M1 is in that situation too: Apple's bootloader is bare-bones and doesn't even support USB, let alone networking (by design). The Wi-Fi firmware is larger than the first-stage and second-stage bootloaders put together. The whole thing boots too fast to go around initializing Wi-Fi (just firmware upload and boot takes a few seconds on these modules...) and associating to a network and phoning home. And due to the SoC design, after boot, no proprietary code remains running on any secondary core with the ability to take over the system; all auxiliary cores running firmware are sandboxed behind IOMMUs, and the main CPU does not have the ability to run a secret supervisor/hypervisor under the OS (it can run a hypervisor but that cannot be done surreptitiously and silently; the guest knows).
And of course, given how Apple is constantly under attack by nation-state-sponsored entities like NSO, they have every incentive to fix security problems and build systems that are very difficult to compromise. To my knowledge, the L5 does not support any kind of secure boot (at least it is not implemented yet; the SoC itself might), nor does it make any attempt at being secure against physical access attacks (e.g. evil maid). The M1 does. I can install my own Linux bootloader, which requires entering my machine owner credentials, and know that nobody else can take over the device without wiping storage entirely via DFU mode, even if they have physical access, at least not without Apple's help (and even then there's ways of hardening that, but we're still working on the details). And I still don't have to delegate all my security to Apple; I can still use full disk encryption and know that even if they reboot the device to take over the boot process, they won't be able to get at my data.
This is not to say the M1 is a security panacea and the L5 is terrible. They each have their pros and cons. Some people might prefer one, some people might prefer the other. That's why we need to educate users about the realities of the devices they choose to purchase, instead of slapping meaningless "RYF" labels on them and discouraging nuanced discussion.