zlacker

>>zdw+(OP)
People like to criticize secure boot around here, but it prevents these kinds of infections (provided of course there are no vulnerabilities in the implementation of secure boot).

Yes, in theory it is possible to prevent these kinds of infections without resorting to secure boot (e.g., by insisting that all the suppliers of components of the motherboard start designing components that cannot be pwned) but so far all the computers you have actually been able to buy that are immune to these kinds of infections achieve that immunity with secure-boot technology.

>>holler+eTa
Can you please explain how Secure Boot helps at all to mitigate this type of attack? I don’t see how it makes it harder to execute the attack, and I don’t see how it has any particular effect on the capabilities of the attack once executed. To the contrary, a BMC compromise of this sort seems like it should be able to arbitrarily override secure boot settings.

It seems to me that, in this situation, secure boot’s only role is to provide a false sense of security, which could make recovery from the attack less likely.

In contrast, verified boot might somewhat mitigate the damage from being able to use the BMC to write arbitrary data to the SPI flash chip. Emphasis on might — at best I expect that it would require an attacker to be a bit more creative in how they design their exploit payload.

>>amluto+TWa
I have never seen someone make a distinction between Secure Boot and boot verification on UEFI/x86, although I suppose it’s a valid one? I suspect the parent post is referring to Secure Boot in the colloquial sense it’s usually used for on x86: validation of the UEFI boot binary using Secure Boot keys followed by OS level trust chaining, usually accomplished by entangling PCR state with disk encryption in some way.

And I think this would deliver a slight level of protection from the BMC: tampering with the firmware image or key enrollment / secure boot state _should_ both break the UEFI root of trust and alter the PCR state and break everything downstream. Of course, all UEFI implementations are holier than Swiss cheese and there are probably a lot of ways to use the BMC to dump or modify memory post-boot anyway, but it does do something.