Purism's Librem 5 To Rely On Secondary Processor For Binary Blobs

[phoronix]

Phoronix: Purism's Librem 5 To Rely On Secondary Processor For Binary Blobs

With not being able to deliver a 100% fully free software / libre system, the Librem 5 smartphone will rely upon a secondary processor for dealing with the necessary binary blobs for hardware initialization to keep them out of touch from the U-Boot boot-loader and Linux kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Librem-5-Secondary-Proc-Blobs

[klokik]

So what's the difference if an M4 core has direct access to the same hardware as A53? They are basically adding one more bootloader (which contains blobs) to the boot process, and brings up the main u-boot, what's the point of doing it on a different core? How will they ensure that it won't do something nasty?

[kpedersen]

Disappointing. Surely this is going to add to the complexity and cost. Seems like an incorrect decision.
Could the correct decision simply to be using DDR3?

This project should always favor freedom over performance. It mentions the training needs to be done each boot but why can the results not be stored?

[Vasant1234]

What a bummer -, it is only 99% open source. They might as well run Android AOSP, it will at least be fast with the caveat that it is 95% open source.

[kpedersen]

Yes, I am actually very surprised after their efforts to settle for 99% open-source.

I am more inclined to believe that some money has exchanged hands to keep the old boys finger on the pulse.

[Danniello]

Hmmm... Sad... I'm not very technical, but if Librem will have closed-source firmware with probably closed source drivers - what is the difference from Android? No closed-source parts that lock-in device for one only system (and in many situations - one only version of this system) was in my opinion the most important part of Librem initiative.

They want add second processor, so if I understand correctly - this second processor will have dedicated software that will handle all "closed-source" parts. "First" processor with "open-source" software will "talk" with second system via some API...

I wonder how big will be this "closed-source" part of Librem. Via analogy: I'm using Linux on my PC, but sometimes I need connect to "closed-source" Windows system via RDP/VNC...

[L_A_G]

It's fascinating to see how there's always more to know about these sorts of things. I knew the fact that most wireless chips using binary blobs and essentially being Turing complete systems in their own right with DMA and everything* would warrant some additional hardware complexity due to their need to remove or mitigate any potential threat caused by blobs, but I didn't think they'd have to do much beyond that.

*If you want to see what a rogue network device, even just a USB connected one can do, just look up PoisonTap and Broadpwn cause it's actually pretty terrifying what a backdoored or hacked network chip can do.

[madscientist159]

Strange excuse; POWER9 for instance has completely open DDR4 training (no blobs needed). See https://git.raptorcs.com/git/talos-h...C?h=06-04-2018 for a taste.

This sounds more like wanting to keep a cheap ARM chip than to actually investigate options. I know POWER9 won't work in a phone, but surely the appropriate technology could be licensed from e.g. IBM and a proper chip fabbed at the quantities expected for a phone?

This is sadly standard operating practice nowadays. Release something that's hyped as open, but when you dig into it it's quite closed, but since it's cheap, people buy it anyway....

EDIT: Oh, and why is the FSF now certifying devices that require blobs to even *boot up*? I'd be somewhat surprised if they did certify this phone, and if they do then it's clear that the time has come for a new certification, one that centers more on Right to Repair (i.e. can get source, can modify operation of device without vendor approval) than the old definition of "blobs in ROM are OK".

Just my personal $0.02 on a troubling trend

[Antartica]

I think there are two separate things to consider in regard to binary blobs:

1. You want to be able to audit the code.

2. You want to be able to modify your code without being beholden to a binary blob.

In this case the FSF is focusing on (2).

I think it's easy to miss the rationale of the FSF to OK that method of having binary blobs. Non-upgradeable code (ROM) running in a separate processor is equivalent to just hardware, not software. Another way to think about it: If nobody can modify it, it doesn't behave as code, and it isn't bound to the four freedoms the FSF apply to code.

I concur that this means that there is code that you can't audit, written by someone else and running on the device, and that is a problem.

But the other problem of binary blobs, that is that you cannot upgrade the kernel because it's beholden to blobs, disappears in this case, as the blobs are rightfully isolated in non-modifiable black box separate from the main processor.

This is akin to the situation of Broadcom's Videocore IV in the Raspberry Pi (although AFAIK the software running in the videocore is not in ROM).

Personally, I think what Purism is doing the right thing, as the phone already has unauditable code running in the modem (cfr. the RIL) and in the SIM card. One can only expect a smartphone to be "clean" in regards to the application processor, and that is what they're striving to keep clean WRT the four freedoms.

[rene]

Disappointing. Surely this is going to add to the complexity and cost. Seems like an incorrect decision.
Could the correct decision simply to be using DDR3?

This project should always favor freedom over performance. It mentions the training needs to be done each boot but why can the results not be stored?

I thought the same, but on a first look at the blog post it sounds they talk about SoC integrated cores, so no additional chip, looks like the Phoronix summary is a bit misleading, ..:

"…has some A53 cores and an M4 core all on the same silicon. The A53 cores run U-Boot and the Linux kernel and the M4 can run bare metal code or a number of liberated Real Time Operating Systems (RTOSes). We decided to write some bare metal M4 code to do the DDR PHY training."