And the 'solution' which is applied is preventing it from being updated. This is the MAIN CRITERIA for their choice of components: whether they can block firmware from being updated. So for example, if there are separate data lines for firmware updates, that's perfect to them.
Conversation
Doesn't matter if it's horribly outdated and/or insecure. The decision making is based on whether they can technically have an OS without proprietary components and no way of updating proprietary components from the OS. That is the goal - and not just a transitional one, really.
1
They'll pay lip service to actually open hardware and firmware but it's not really part of what they want to achieve. End goal is RYF certification and they want to obtain that through making the firmware count as 'hardware' by preventing updates to it to make it out of scope.
2
2
So you keep repeating this over and over but Purism has very explicitly rejected this characterization and clarified they will continue to allow full user control over their firmware.
1
"RYF is clear that any software that can be updated using the CPU must be free software. Our (Purism’s) interpretation is that it does not force a requirement that firmware cannot be upgraded out-of-band from the CPU, or external to regular software updates."
2
So, exactly what I said: blocking the ability to ship firmware updates, but not necessarily going out of the way to stop there being any way to do it if it isn't required to block updating it from the OS. They HAVE blocked "out-of-band" updates to accomplish their main goal.
2
Okay so in other words firmware is read only from the perspective of my OS and can't be tampered with unless I pop the back off my phone physically and update by hand. I have the schematics and everything so this is ideal.
I like that.
1
It's not possible to update via OS, not from the perspective of the firmware. No one said the baseband can't receive a firmware update pushed via a cell phone tower, etc. No one said there is verified boot for it. No one said they picked components with security support.
1
1
The baseband is on a separate gemalto daughter card so that is its own black box so I don't think that is in scope here.
That is untrusted by the design of the hardware. Limited access to OS memory .
1
It's not specific to the baseband. It applies to the SoC and the other components. It's also not untrusted in any sense. As a general rule, Linux kernel drivers trust hardware components. You seem to be falling for the false dichotomy of DMA vs. non-DMA being about isolation.
1
Components with DMA can be untrusted, and often are, due to usage of IOMMUs. Components without DMA can be trusted, and often are, due to their role in the design of the device along with the design / implementation of typical drivers trusting the hardware that they support.
When someone writes a driver for hardware, they're rarely treating that hardware as an attacker. Wi-Fi, much like a cellular baseband, also runs a large RTOS requiring substantial hardening, auditing and regular security updates. You don't get that with these components.
1
If you're simply going to hand an attacker persistent local code execution on a Wi-Fi / Bluetooth / Cellular SoC you're trusting them with direct access to the kernel driver and other code supporting the device from the OS. It's a whole lot more than that too. What about privacy?
2
Show replies