I don't really see how something designed to be locked down in a way that even a Pixel is not (i.e. going out of the way to sabotage firmware updates to remove that option from users and operating systems) is more flexible, or what advantage there is to sketchy component choices.
Conversation
Can you elaborate on sabotaging firmware updates? This point has remained unclear.
2
"The SPI flash will be read only so the firmware blobs [run on the secondary processor] can’t be modified without the user knowing."
This all stems from seeking RYF certification and making use of the secondary processor exception.
1
This is just one example. There are other ways it is approached. It is also part of how they make their laptops. So, if the firmware has signature verification, they'll block updating it somehow. If it doesn't, it'll still end up being blocked since components lack open firmware.
1
If there is a security feature that they see as reducing 'freedom' (with a very odd way of defining freedom) it will be deliberately left either not set up or permanently disabled via fuses. They see it as failure if there is any signed or closed firmware that can be updated.
1
1
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.
1
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."
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
And when "out-of-band" means attaching special debug cables to flash firmware onto components where they haven't done that, I'm pretty skeptical that it has real world relevance to users that are not just developers but developers taking an extreme approach.
Right. So users are free to update it if they like, just not via the OS CPU. That seems reasonable. I prefer this even, as it means if my day to day OS is compromised and later patched I don't need to wonder if my firmware was backdoored.
2
For something as dangerous and seldom as firmware updates I would rather do this out of band of my normal internet connected OS.
1
Show replies