4 ms·

Does this defend against any additional attack surface that wasn't already defended by the UEFI Secure Boot standard?

wmf 6y ago
Yes, UEFI Secure Boot defends against OS/bootloader malware while this defends against flashing malware into the UEFI firmware itself.
- arpa 6y ago
  Wait so if i flash malware into the firmware, i should also have a spare fresh EPYC CPU i could install?
  - SaltySolomon 6y ago
    The keys for trusted compute, memory encryption and such are saved inside the CPU, so if you change the CPU you also loose all those keys.
  - jacoblambda 6y ago
    Yes, I think that would be a valid way to bypass the protection. With physical access you can bypass just about any protection given enough money and time. In a data centre context, the damage you can do is rapidly minimised by rapidly increasing the amount of capital and time required to access more of the DC. The more important change is that without this feature, malware could theoretically install itself into the firmware without requiring physical access. Now it should be just about impossible to break the chain of trust without a person physically tampering with the machine. Note: I should mention that I think this is such a massive double edged sword (maybe double edged shield is a better term). This lets you build a threat model that accounts for everything up to physical access. This however also has such a massive opportunity to be an incredibly anti-consumer feature that I fear to see how it will be used. I wish they would have required a physical switch to enable/disable the feature. I do however understand how adding such a feature could complicate its implementation quite a bit.
- non-entity 6y ago
  So if I understand correctly, I wouldn't be able to flash, say coreboot?
  - arpa 6y ago
    Of course.
- pantalaimon 6y ago
  The joke is that UEFI got so complex that we can have malware there in the first place.
rasz 6y ago
It defends big vendors against secondary market.

wmf 6y ago

Yes, UEFI Secure Boot defends against OS/bootloader malware while this defends against flashing malware into the UEFI firmware itself.

arpa 6y ago
Wait so if i flash malware into the firmware, i should also have a spare fresh EPYC CPU i could install?
- SaltySolomon 6y ago
  The keys for trusted compute, memory encryption and such are saved inside the CPU, so if you change the CPU you also loose all those keys.
- jacoblambda 6y ago
  Yes, I think that would be a valid way to bypass the protection. With physical access you can bypass just about any protection given enough money and time. In a data centre context, the damage you can do is rapidly minimised by rapidly increasing the amount of capital and time required to access more of the DC. The more important change is that without this feature, malware could theoretically install itself into the firmware without requiring physical access. Now it should be just about impossible to break the chain of trust without a person physically tampering with the machine. Note: I should mention that I think this is such a massive double edged sword (maybe double edged shield is a better term). This lets you build a threat model that accounts for everything up to physical access. This however also has such a massive opportunity to be an incredibly anti-consumer feature that I fear to see how it will be used. I wish they would have required a physical switch to enable/disable the feature. I do however understand how adding such a feature could complicate its implementation quite a bit.
non-entity 6y ago
So if I understand correctly, I wouldn't be able to flash, say coreboot?
- arpa 6y ago
  Of course.
pantalaimon 6y ago
The joke is that UEFI got so complex that we can have malware there in the first place.

rasz 6y ago

It defends big vendors against secondary market.