Yep the firmware paragraph of his article is the only one worth reading as it raises valid points.
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.
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.
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?
Maybe this is all-solved already, SDMA is not an issue other than having a blob, and we should not care about that.
@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!
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.