Its called Secondary market, nothing black about it. https://www.youtube.com/watch?v=TxZ21Q0VSdE

BIOS (UEFI) level rootkits

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.

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.

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)

> 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.

Attacker might flash a tampered BIOS from inside a VM makes total sense. It’s surprising how many SPI ROM there can be in a box, and how basically they’re all waiting there to be exploited.

Cloud vendors should be using coreboot, not UEFI.

Not sure why downvoted. I run blobless coreboot for precisely this reason. My only regret is not being able to find newer x86_64 gear that supports it. OTOH you can still buy in-production arm64 boxes that boot with zero blobs (RK3399).

One of the cloud vendors created UEFI.

Then they know full well how bad it is!

*Jokes aside, I think Intel created UEFI (for Itanium?), not Microsoft?

The consortium has AMD, Intel, and Microsoft listed as contributors, so even if they didn't initially create the thing, they had a hand in it. The executable format used for UEFI is PE, which is telling.

Their statement says "It is a defense-in-depth feature", so maybe not?

is the think of the children excuse.