LWN: Comments on "Private memory for KVM guests"

Private memory for KVM guests

farnz — Mon, 11 Apr 2022 08:06:59 +0000

No, it can't, because you're doing a remote attestation protocol.

The protocol described for TPM-based remote attestation in this PDF is the sort of thing that's going on, with the TPM role being taken by the processor. The core to stopping the hypervisor from playing silly games is that you don't directly send back the attested value - instead, you use the processor's security enclave as the equivalent of a client certificate in a TLS type protocol.

Because the processor mixes in various details of the guest to the final secret it generates, you know that the guest hasn't been modified - modification would result in a guest certificate that didn't match what you were expecting - and thus you're protected against the hypervisor replacing instructions. In the event that the hypervisor does replace instructions, you end up sending the remote server the "wrong" certificate, and it can identify that you're not a trusted code version - either a known code version that's got security bugs, or an unknown locally modified version of code.

This all, of course, assumes that Intel and AMD have implemented the security parts of their processor correctly, such that attacks like the Spectre family don't work against a secure VM.

Private memory for KVM guests

LtWorf — Mon, 11 Apr 2022 07:11:06 +0000

But for 2) the hypervisor could just replace the instructions to perform the check with whatever else places the wanted value into the wanted register no?

Private memory for KVM guests

excors — Sun, 10 Apr 2022 19:35:15 +0000

I think the simplified version is: The host can't emulate the TDX/etc hardware, because that contains a private key known only to Intel/etc. The host could trick its guest into accepting a fake TDX attestation by cleverly patching the guest's verification code, but that doesn't matter because it's meant for *remote* attestation: the guest sends the signed attestation report over the network to some already-trusted machine, which verifies it against Intel's public key and checks that the TDX hardware says the hypervisor has properly enabled memory encryption etc, before sending sensitive information (e.g. encryption keys for the guest's disks) back to the now-trusted guest.

Private memory for KVM guests

ssmith32 — Sun, 10 Apr 2022 17:42:13 +0000

For (2) , doesn't it still assume some guest instructions are allowed to run on the processor directly by the host?

What prevents the host from loading guest programs into an entirely virtualized CPU?

Other than the complexity involved in emulating an entire set of CPU behaviours..

Private memory for KVM guests

jhoblitt — Sat, 09 Apr 2022 02:20:24 +0000

The same issue applies to memfd in general as there is no protection against a malicious kernel. Does it make things more difficult for an attacker? Smart people seem to think so. As a user of public cloud, I would not consider this to mitigate any risk from the hypervisor. I would consider hardware support for encrypted memory a risk reduction. However, that would only be for the case where you assume the hypervisor was not comprised before the guest booted. I don't see anyway to provide concrete security guarantees against a malicious hypervisor that could be trapping on any special security enclave instructions.

Private memory for KVM guests

pbonzini — Fri, 08 Apr 2022 06:23:52 +0000

There are two parts in this:

1) for pKVM (the Arm one) yes, you are. In that case the idea is just that the vendor can see the hypervisor's code and trusts it to protect the precious DRM'd movies

2) for TDX (Intel) and SEV-SNP (AMD) the guest gets an attestation signed by the processor vendor, and can check that the contents of the memory are as intended and that any debug mode is not enabled. In that case the hypervisor can mess with encrypted memory but that will result in either the host or the guest crashing. That's fine because these confidential virtualization mechanisms don't promise availability (the host can just decide not to run the guest at all).

For devices (block, network) the solution is to encrypt all the things and keep keys for the encrypted disk in the initramfs (which is included in the above-mentioned attestation).

Private memory for KVM guests

ras — Fri, 08 Apr 2022 03:17:31 +0000

I don't know, but my guess is "yes". It reminds me a polices forces assurances they will police their own wrong doings.

I was hoping for a discussion on AMD's Secure Encrypted Virtualization.

Private memory for KVM guests

bartoc — Fri, 08 Apr 2022 00:45:55 +0000

Even here you're still trusting the host not to be malicious right? As it could just .... not do all this stuff and tell you (the guest) that it did.

Seems useful to defend against bugs though.