search

AMDESE / AMDSEV

AMD Secure Encrypted Virtualization
272 stars 84 forks source link

Blocking a guest's ability to generate (legitimate) attestation reports? #206

Open CookieComputing opened 4 months ago

CookieComputing commented 4 months ago

Hi folks,

I was taking a look at the 2023 LPC CC microconference talks, and I ran into an interesting but brief discussion about preventing guests from generating further attestation reports. It was mentioned that one way we could prevent a guest from generating an attestation report again is to scrub the VMPCK keys from the guest, such that there is no way to communicate with the PSP. I looked into the ABI to see if there was an explicit ioctl command exists to trigger this, but it seems like the VMPCKs reside in GCTX. Is this as simple as wiping those keys from the GCTX? How would I go about doing that?

Is it related to SNP_DECOMMISSION? Using this command would certainly delete the guest context (and the VMPCKs), but would decommission the guest, which isn't exactly what I think the intent of this conversation was.

This aside, I'm curious about what were the implicit consequences of scrubbing the VMPCKs? Obviously I can imagine we can no longer interact with the PSP (as stated in the video), but I'm not familiar with additional complications that may extend beyond that. Are there any other suggested/recommendation approaches for this idea?

tlendacky commented 4 months ago

The hypervisor wouldn't be able to wipe them from the GCTX, since that is owned/controlled by firmware.

Only the guest itself would be able to scrub VMPCKs by removing them from the SECRET_PAGE that is created and provided to the guest at LAUNCH.