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.
Conversation
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
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
Replying to
The choice is between being able to update it (as would be the case the normal way) or not being able to update it.
1
I'm talking in general about the approach to all of the firmware, not only this specific case. I linked this as an example of an extreme case where they are willing to go far out of the way to prevent updates. Not particularly interested in continuing a discussion going nowhere.
The OS can install updates for the late boot chain. OS cannot install updates for this code on the secondary processor. That's the entire reasoning behind them doing it: preventing this proprietary code from being updated at all costs. It's the approach to ALL of the firmware.
1
In many cases this can be done by flashing fuses in a way that purposely bricks the ability to install updates, and similar approaches. In this case, they had to go further out of the way to break the ability to update it. Goal is simply making the OS / user unable to update it.
1
Show replies