I managed to get that much from the article but I still feel I'm missing a few pieces here. Are UEFI rootkits an actual concern, like are they common in the wild? Why should the responsibility of detecting them rest with the processor? How is this related to the Secure Encrypted Virtualization?
There have been a couple in the wild, but they aren't super common.
They've become a bigger concern with UEFI since it has a massive attack surface compared to legacy BIOS.
For a processor sitting in AWS / Azure, they want guarantees, and they're the ones EPYCs are designed for.
The responsibility has to rest with the processor, since it's the only thing executing code prior to UEFI. What it's doing is validating that UEFI was cryptographically signed with the correct key prior to running any UEFI code.
When it's first used, it is saving the key for the vendors UEFI implementation and won't allow it to proceed if the root signature ever changes (think something similar to root certs for HTTPS).
It's only relevant to Secure Encrypted Virtualization insofar as they are both implemented inside the PSP which is a separate ARM core that runs at a higher privilege level than the x86 cores (and is the core that actually initializes the x86 cores).
This is how all phones have worked for many years, but apparently it's now becoming a thing in servers too.
> Are UEFI rootkits an actual concern, like are they common in the wild?
If one segment needs to worry about UEFI rootkits, it's cloud vendors. Very dedicated (nation-state sponsored) attackers could burn/use a zero-day hypervisor escape to installs a UEFI rootkit that tampers with the processor's integrated HSM (as said in the article, tampering with it has already happened and the exploits have been patched by AMD). As I understand it, If a vendor uses full memory encryption, the above exploit could lead to decrypting and exfiltrating other customers' data.
im3w1l|5 years ago
0zymandiass|5 years ago
They've become a bigger concern with UEFI since it has a massive attack surface compared to legacy BIOS.
For a processor sitting in AWS / Azure, they want guarantees, and they're the ones EPYCs are designed for.
The responsibility has to rest with the processor, since it's the only thing executing code prior to UEFI. What it's doing is validating that UEFI was cryptographically signed with the correct key prior to running any UEFI code. When it's first used, it is saving the key for the vendors UEFI implementation and won't allow it to proceed if the root signature ever changes (think something similar to root certs for HTTPS).
It's only relevant to Secure Encrypted Virtualization insofar as they are both implemented inside the PSP which is a separate ARM core that runs at a higher privilege level than the x86 cores (and is the core that actually initializes the x86 cores).
This is how all phones have worked for many years, but apparently it's now becoming a thing in servers too.
judge2020|5 years ago
If one segment needs to worry about UEFI rootkits, it's cloud vendors. Very dedicated (nation-state sponsored) attackers could burn/use a zero-day hypervisor escape to installs a UEFI rootkit that tampers with the processor's integrated HSM (as said in the article, tampering with it has already happened and the exploits have been patched by AMD). As I understand it, If a vendor uses full memory encryption, the above exploit could lead to decrypting and exfiltrating other customers' data.
fulafel|5 years ago
rasz|5 years ago