Components *should* also be designed without persistent state including not having any persistent firmware. It's a good thing to force it to be uploaded from the OS. It gets an extra layer of verification as part of verifying the OS, it's much less of a black box and is optional.
Conversation
The main project that I'm referencing is taking things in the opposite direction. They prefer components with persistent firmware / state, which they prevent users from updating, and they've gone out of the way to make complex workarounds turning it into more of a black box.
1
3
See puri.sm/posts/librem5-. It's the approach being taken across the board. The proprietary hardware / firmware is still there, just set to be hard-wired with updates prevented, or uploaded via complex workarounds to avoid having it under the control of the OS and updatable.
2
4
I can't support hardware going out of the way to prevent security updates and various important security features. Outside of semantic games, it's less open. At the very least ship a fully unlocked device (fuses not blown, etc) and let people choose rather than forced insecurity.
1
A more open device would be one where you can purchase the device with fuses not blown so you can set your own signing keys for the low-level firmware or leave it in dev mode and install what you want, including the standard firmware security updates, or an open source rewrite.
1
1
1
Having complex firmware with updates intentionally blocked isn't sane. At the very least users should have the option to install security updates fixing issues like remote code execution vulnerabilities. Known vulnerabilities in Wi-Fi, etc. are worse than theoretical backdoors...
1
1
4
Replying to
I don't have enough information to know if they're "gratuitously controlling what you can do with your own device" or "implementing a proper hardware security model where attack surface for alterring firmware has been removed". If the latter, it's a good thing in my book.
2
Replying to
I don't see how any attack surface has been removed and they've certainly prevented firmware security updates. Their goal is quite explicitly preventing the firmware from being updated through the OS, including going out of the way to have another processor upload it necessary.
2
Replying to
The link was just about DDR training, which has nothing to do with the type of firmware you're talking about. The goal was to make the machine boot without having to run proprietary firmware on the main cpu, and their achieved it cleanly, with no tradeoff here.
1
Replying to
There is a substantial amount of proprietary firmware on the main CPU. They consider it fine because it's not set up in a way that it can be updated. I provided the link because it shows how far out of the way they're willing to go to prevent being able to update the firmware.
2
There are certainly downsides to not being able to update it, and there isn't a downside to the OS having the ability to upload updated firmware (ephemerally) rather than having specific versions hard-wired into the hardware. Blocking bug fixes / security updates isn't progress.
In a situation where the OS has been completely subverted / taken over by an attacker, I'm having a hard time seeing why it matters if it can upload ephemeral firmware, even if the hardware doesn't perform the expected signature checks. It can't be portrayed as an improvement.