Peter Robinson about the Librem 5

Hardware Librem 5
1

read here: https://nullr0ute.com/2017/10/why-im-not-backing-the-purism-librem-5-phone/

Peter starts with “While I applaud the general principals and ideas of a fully open rights protecting phone I can’t help but feel that the group doing it either are being false at worst or naive at best with some of their statements.”. He criticizes the use of the i.MX series in the phone and points the problems of privative firmware and other inconvenient aspects.
As he said it would be better to use Qualcomm 820c/600c SoCs.

What does Purism has to say about this?

2 Likes
2

I wonder why he didn’t (I assume) reach out to Purism before writing something like that, if he truly thinks it is a laudable cause.
Actually, I think Purism already has clearly said why Qualcom was not a choice. I get the impression that he is not too well informed, but maybe @nicole.faerber can add to that?
Especially on his claims that i.MX need closed source firmware to be usable.

2 Likes
3

You may want to read this:


(and the comments, esp. by Bero)

And this:

So, both i.MX8 and 820c are interesting for running Gnu/Linux. But there are also difficulties. No one knows, if an open bootloader for 820c is really happening soon. Another question is, if you can buy relatively small amounts of them, and what the price is.

4

He does not say that i.MX needs such a firmware. He claims that the i.MX8 is a bit oldish and not really a ‘phone-oriented’ SoC. - I actually think, if the i.MX8 is available for a decent price, it should be a fine SoC for the phone.

5

Hi all,

it has already been pointed out - while the Qualcomm CPUs are indeed very nice, powerful and power efficient but the built-in wireless basebands (mobile, WiFi, potentially BT too) are included on the CPU silicon die and share many parts of the main system with the basebands, especially RAM. While this is clever to save extra RAM chips for these basebands or chip size, it has the massive drawback that these basebands need to be able to access the main memory for their purpose. This means they have direct access to the main memory bus without control from the main CPU core. This again means that the baseband firmware could, at least in theory, access private data from the main memory without the user noticing. If you trust the baseband firmware, then this is not much of a problem. But especially the mobile modem’s baseband firmware is huge implementing complex protocols and runs an operating system on its own. You have no chance to control, debug or confine this firmware.

This is why we can not trust this firmware and must avoid a combined main CPU - baseband - RAM usage. So this rules out all Qalcomm SOC with integrated wireless radios which are basically all chips that would be usable for a phone.

The next issue is free GPU drivers. While there are some drivers for Qualcomm Snapdragon (freedreno) these are not as advanced as the Etnaviv for iMX.

The iMX6 is not ideal, yes. But we have high hopes to be able to use the iMX8, preferably the iMX8X which should be much more power efficient than iMX6.

I hope this clears it up a bit. If there are more questions or something unclear feel free to ask.

Cheers
nicole

13 Likes
6

@nicole.faerber, Yes, thanks a lot! Based on that I totally agree with the decission.
Could you say a few words on the claimed need for SDMA and media decoding firmware?
I guess the former is vital, the latter a bonus? :slight_smile:

2 Likes
7

@sverris: read his ramble again. He says SDMA and media decoding firmware is needed.
…

So there are at least 3 projects working on ARM64 laptops… I think they should just join efforts. Or Purism should hire them, as @todd-weaver said in one interview (if I remember correctly) that this could be an interesting option for the future.

8

Yep the firmware paragraph of his article is the only one worth reading as it raises valid points.

VPU
Skimming through the media encode/decode unit (the Video Processing Unit) and its firmware, you are right @Caliga it is not vital and can even be permanently disabled by burning a fuse. Where to put the “bonus” cursor, it is quite important if you want to consume medias on your phone as Robinson inputs.
I guess VPU firmware is insensitive security-wise, it can only convert media streams to frames… but remains FLOSS-wise a binary blob. It should be under control of the CPU, although it is a programmable independent module and has SDMA access.

SDMA
TL:DR Experts needed on the potential surface for side-channel, physical SDMA attacks.

Smart Direct Memory Access looks like a more serious issue. Is it vital, no clue. It is in charge for a lot of DMA requests, their customization and scripting, between the externals and the application processor domain. (basic DMA can be done through General Purpose Media Interface)
SDMA is an independent 32-bit RISC chip… well others know better + you can dive in the iMX6 reference manual.
http://billauer.co.il/blog/2011/10/imx-sdma-howto-memory-map/
http://blog.petri.us/sdma-hacking/part-2.html

SDMA RAM has some 20-ish NXP-written basic scripts, but more it has a 4kB programmable space for OEM(Purism here)-written scripts. Basic scripts are already powerful.
From what I understood, SDMA initialization happens during bootloader stage. Loading scripts in SDMA after that can be blocked by setting a flag in the complex lock register. Then, as Robinson mentions, the linux-kernel black-box 2kB driver handles sdma. I think the control ARM cores have over those SDMA scripts, with Host Enable and Host Override flags, happens in there.

How sensitive is it from a security standpoint? That is where an expert would come handy, if I take a paranoïd stance I could imagine a script fooling linux kernel and allowing a full dump, of both external memory (DDR4 RAM…) and the internal RAM, to an external bluetooth device in the wink of an eye… Full disk encryption is not yet sorted, so how about RAM encryption? :slight_smile:
Maybe this is all-solved already, SDMA is not an issue other than having a blob, and we should not care about that.

iMX blobs
@todd-weaver @nicole.faerber @zlatan-todoric iMX SOCs are probably the best option you could choose and I am happy with it. Being committed as you are at removing blobs is a real challenge with all NDAs involved and the number of sub-modules in the iMX city (see below).
It is a tedious work, but achieving, during next months, a comprehensive listing of which modules :

  • can be used blob-free,
  • are under NDA,
  • are sensitive on the physical security level ,
  • are vital for a usable phone / are planned to be used,

would I think be appreciated a heck of a lot by your user base!

IMX6_block_diagram
IMX6_block_diagram695×704 44.5 KB

Here on the forums already emerged concerns about boot modules (boot ROM, fusebox), CAAM, SNVS, CSU(Trustzone) ; in this particular thread popped the VPU and SDMA ones ; who knows, next week someone might come up the Power Management Unit.

2 Likes