Something important to note is that this is largely a BMC firmware problem - the hardware can be securely configured to maintain CIA against the host, just sometimes it is not.
A lot of these debug features are re-enabled on SoC reset so there are quite interesting attacks you can do there just given access to reboot the SoC. Attack before the OS has been loaded and has had time to disable the features and you win.
Right; then it comes down to platform design and whether you can reboot the soc in a mode that both reopens the bridges and doesn't kill the host, though that's not relevant if you're accessing it from the UART debug interface.
FWIW the mitigation patch in OpenBMC turns off all the bridges early in u-boot to minimise the race window for system reset/AC cycles.
Obviously would be better if it was possible to avoid the race window entirely (i.e. bridges default to closed, can be strapped open by the platform designer, and opened as required by firmware). We had asked for hardware changes along these lines for future generations (but may need to push a little harder...)
bluecmd|7 years ago
These are silicon issues as far as I know.
amboar|7 years ago
FWIW the mitigation patch in OpenBMC turns off all the bridges early in u-boot to minimise the race window for system reset/AC cycles.
Obviously would be better if it was possible to avoid the race window entirely (i.e. bridges default to closed, can be strapped open by the platform designer, and opened as required by firmware). We had asked for hardware changes along these lines for future generations (but may need to push a little harder...)