The most plausible hypothesis of how this attack works is by corrupting firmware loaded at power-on time over SPI. Secure boot would absolutely protect from that by rejecting the signature of the modified code.
By hey, I get that Newsy groupthink means secure boot bad.
>is by corrupting firmware loaded at power-on time over SPI.
>Secure boot would absolutely protect from that by rejecting the signature of the modified code.
Why couldn't you also change out the keys so the signature does match?
Doing so means compromising the TPM on the BMC module which is much harder to do. It's not something that can be done downstream in the supply chain, as this attack is purported to have been.
Secure boot is in no way bad :-) Ofcourse, it must in fact be the first point on any sane security checklist.
And one of the most common attacks aka. malicious firmware is prevented by using secure boot.
Many other classes of attacks like forcing the microcontroller to delete all its data, opening up the debug JTAG port of the microcontroller, preventing the log of certain security events etc. can be achieved with the right settings.
Though these are just remote possibilities with high levels of complexity, so is changing a production design of a board.