[0zymandiass]

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.

[im3w1l]

Oh the UEFI code is run by the main processor.. somehow I had always assumed it was running on some micro-processor on the mobo.

[0zymandiass]

Ah. Yeah.

The motherboard just loads BIOS/UEFI into a predefined memory address and then starts the CPU

This is a pretty good explanation https://manybutfinite.com/post/how-computers-boot-up/

> In a multi-processor or multi-core system one CPU is dynamically chosen to be the bootstrap processor (BSP) that runs all of the BIOS and kernel initialization code

These days, the "bootstrap processor" is a separate core that your OS can't see. On Intel it's the IME (running Minix) and on AMD it's the PSP (ARM TrustZone)