On Thursday, 7 July 2022 19:37:16 BST Sharpened Blade via devel wrote:
If it is really compromised, then you have to assume anything the vm
sends
you is fake. As far as the owner of guest knows, there could not even a a
real vm, only a ssh shell that looks like it.
In a real situation, the guest owner would send the host owner a
"starting
disk" or ISO. Then the host would tell the trusted cpu to boot a iso that
sends the signature to the host, and also boot a modified iso in a normal
hypervisor, and emulate the trusted part of the cpu. When the normal
hypervisor vm wants the signature, the signature of vm1 is returned. The
system in the normal hypervisor could also just lie to any connections
outside the host system, so even if it knows its backdoored, it still test
the guest owner its not.
This is a solved problem, and you need to read up on how remote attestation
works in the presence of an attacker to understand fully how it's solved.
The core to the trick is that the CPU prevents the hypervisor from seeing into
the state that belongs to the guest (measurements, memory content etc), unless
the guest explicitly tells the CPU to share that memory. It does this using
cryptographic primitives so that even an attacker who can monitor the DRAM bus
externally to the CPU cannot see into guest state.
You can thus use key exchange protocols designed to work over a public channel
(Diffie-Hellman for a simple example) to set up an encrypted channel between the
guest and the remote system such that the hypervisor can only deny service -
it cannot see into the channel, and thus cannot lie to the guest or its remote
attestation service.
The same techniques are used in TLS to set up a secure channel between a
service provider like
https://start.fedoraproject.org/ and a user like my
Fedora laptop
--
Simon Farnsworth