Comment by marcan_42
4 years ago
> I was under impression that it was the whole point of the exercise. It would be interesting to know otherwise.
It absolutely wasn't. Look into it. In every case, the blob ends up running on the RAM controller CPU and supposedly finishes running and is done. The whole point of the exercise was obfuscating the process which is used to get to that point such that it avoided the main CPU physically moving the bits of the blob from point A to point B. Really.
> 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.
That is incorrect (great, now they either don't know how their own phone works or they're lying - see what I said about obfuscation? It's great for confusing everyone).
The M4 core code is not proprietary; it's the pointless indirection layer they wrote and it is not loaded from that SPI NOR flash. It's right here:
https://source.puri.sm/Librem5/Cortex_M4/-/tree/master
That open source code, which is loaded by the main CPU into the M4 core, is responsible for loading the RAM training blob from SPI flash (see spi.c) and into the DDR controller (see ddr_loader.c).
The actual blob then runs on the PMU ("PHY Micro-Controller Unit") inside the DDR controller. This is an ARC core that is part of the Synopsys DesignWare DDR PHY IP core that NXP licensed for their SoC. Here, cpu_rec.py will tell you:
firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem.bin
full(0x5ac0) ARcompact chunk(0x4e00;39) ARcompact
The normal way this is done is the DDR training blob is just embedded into the bootloader like any other data, and the bootloader loads it into the PMU. Same exact end result, minus involving a Cortex-M4 core for no reason and minus sticking the blob in external flash for no reason. Here, this is how U-Boot does it on every other platform:
https://github.com/u-boot/u-boot/blob/master/drivers/ddr/imx...
Same code, just running on the main CPU because it is absolutely pointless running it on another core, unless you're trying to obfuscate things to appease the FSF. And then the blob gets appended to the U-Boot image post-build (remember this just gets loaded into the PMU, it never touches the main CPU's execution pipeline):
https://github.com/u-boot/u-boot/blob/master/tools/imx8m_ima...
Purism went out of their way and wasted a ton of engineering hours just to create a more convoluted process with precisely the same end result, because somehow all these extra layers of obfuscation made the blob not a blob any more in the FSF's eyes.
The security question here is whether that blob, during execution, is in a position to take over the system, either immediately or somehow causing itself to remain executing. Can it only talk to the RAM or can it issue arbitrary bus transactions to other peripherals? Can it control its own run bit or can the main CPU always quiesce it? Can it claim to be "done" while continuing to run? Can it misconfigure the RAM to somehow cause corruption that allows it to take over the system? I have seen no security analysis to this effect from anyone involved, because as far as I can tell nobody involved cares about security; the whole purpose of this exercise obviously wasn't security, it was backdooring the system into RYF compliance.
> great, now they either don't know how their own phone
Who's "they"? This is an unofficial community wiki.
If it's a random community member then this is just further evidence that the way Librem presented things and what they did confused people into thinking it actually had a practical purpose, when it was purely a way to rules-lawyer their way into getting RYF.
Hi, I'm the "random community member" who wrote that FAQ answer. Thanks for investigating how this works. Where is the file cpu_rec.py located? I can't find it.
I will edit the FAQ answer to clarify that the DDR training blobs are being executed on an ARC core in the DDR controller, and not on the M4 core. I was going off what Angus Ainslie wrote (https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...) that 'the M4 is the “secondary processor” that handles the blobs', and I conflated "handles" with "executes".
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, and Ainslie's article on the Purism web site and Nicole Faerber's talk (https://media.ccc.de/v/Camp2019-10238-a_mobile_phone_that_re...) both explained how Purism is using the secondary processor exception in the RYF rules.
It is not like Purism had any better options in terms of SoC's that it could have chosen for the Librem 5. Raptor Computing is now facing the exact same problem with the proprietary Synopsys DDR4 timing blobs in the POWER 10 processor, so this is actually a common problem with most modern processors. 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.
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 and make the Librem 5 no different than an Apple device with an M1 processor, which is literally a black box. Forget the fact that the L5 is the first phone to have free/open source schematics since the GTA04 in 2012 and we know the 1267 components on its PCBs, plus we have 7000 pages of documentation for the i.MX 8M Quad processor, and everything is running free/open source drivers.
There is only so much code that you can hide inside 58 KB of blobs and that early in the boot sequence, you can't rely on anything else being operational in the device, so you would need to have all the code to initialize and control components on the phone. 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. It isn't hard to verify that the blobs that are stored inside the L5's SPI NOR Flash chip are the same ones being distributed by NXP, so then you are left with the theory that NXP or Synopsys are distributing blobs that do something malicious, which would be suicidal for either of those companies if anyone ever discovered it. Supermicro's stock lost 40% of its value after Bloomberg published one story about the Chinese government inserting spy chips in Supermicro motherboards, and nothing in Bloomberg's article was verifiable. Companies like NXP and Synopsys are very unlikely to risk their businesses, even if the NSA asks them, so I find the whole scenario far-fetched.
7 replies →