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...
Conversation
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.
2
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.