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.
Conversation
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
Replying to
The link has nothing to do with the topic you're complaining about them doing, which I haven't seen any evidence of. The DDR training thing is a purely positive change.
1
Replying to
I don't see what's positive about it and I'm giving it as an example of an extreme case.
1
Replying to
It's positive in that you don't have to trust/audit that the DDR training blob is not doing anything funky it shouldn't with the state of the main cpu, because it doesn't have access to it.
1
Replying to
That's not how it works. They're not avoiding running the code on the main CPU, they're avoiding having the OS in control of the firmware that's uploaded to the controller. You're misunderstanding what was changed. Issue for them is it didn't have persistent state in hardware.
In other cases, they can just block updating the firmware from the persistent copies. In this case, the hardware has no persistent copy and needs it uploaded to the controller. Usually, the OS has the firmware and uploads it. The OS doesn't run the code, it uploads the code.
1
Their issue is with the ability to update the firmware that's being uploaded, which is against the rules they are trying to satisfy. Their concept of open is it having hard-wired persistent firmware instead of the OS uploading it. This was a case where they had to hack around it.
Replying to
As I (re-)read it, they're making the M4 responsible for getting the DDR controller into an initial usable state for the main cpu to boot rather than having uboot on main cpu need to interface with DDR controller and upload proprietary firmware.
1
There is never a choice to do this nonpersistently at real os runtime because DDR needs to be up beforehand. Choice is just between uboot having to handle it or secondary cpu handle it.
1
Show replies