4 ms·
I think part of the motivation here is tying it in with the PSP and having the root of trust be the processor and not processor for some stuff and motherboard f
by MertsA 5y ago
I think part of the motivation here is tying it in with the PSP and having the root of trust be the processor and not processor for some stuff and motherboard for others. For PSP related stuff it does make sense to centralize on AMD rather than having every vendor have their own implementation of some platform security standard. It's dumb to let motherboards effectively brick a CPU but there reasonably could be a way to have the root of trust on the CPU and extend that to firmware signatures so you could remotely attest BIOS versions, etc.
I've mentioned this elsewhere but they could have just added some way of writing this signature out of band or allow bypassing it via a solder bridge on the top of the package like how SPD works on memory but require a separate interface for writing to it. Requiring a $10 I2C to USB adapter to change the key is not that onerous and it would be simple enough for OEMs to flash whatever they wanted on it and it could still be cleared for resale. For protecting against an APT doing shipment interdiction attacks quite frankly that sounds like a bunch of B.S. as all locking the key on the processor does is require the processor to be swapped out during an attack as well. If someone is going through the effort to intercept hardware in transit to flash custom malicious firmware on it, the cost of swapping the processor as well is not that extreme.
If they're going to keep the strategy of blowing fuses on the CPU die then AMD should be the ones doing it and they should make a vendor specific SKU so that trying to figure out if a CPU is vendor locked or not isn't such a minefield.