Re: SVSM initiated early attestation / guest secrets injection

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Jan 13, 2023 at 06:22:38PM +0100, Jörg Rödel wrote:
> Hi Daniel,
> 
> On Thu, Jan 12, 2023 at 02:39:24PM +0000, Daniel P. Berrangé wrote:
> >  4. SVSM requests an attestation report from SEV-SNP firmware, embedding a
> >     hash of the attestation server public key and its own public key.
> > 
> >  5. SVSM transmits the attestation report and the two public keys on the ISA
> >     serial port
> 
> This basically emulates the secret injection mechanism that was
> implemented for SEV and SEV-ES by the firmware, right?
> 
> I see a problem here which allows a potential host owner to steal
> the secrets from the attestation server. Maybe I am wrong, but I think
> the following is possible with the above sequence:
> 
> 	1. Host owner sets up a CVM like the guest owner would do, with
> 	   the same SVSM and Firmware binaries, same initial state and
> 	   so on, so that the initial measurement is the same as if the
> 	   VM was setup by the guest owner.
> 
> 	2. Host owner attaches a different disk image with malicious
> 	   content, e.g. a boot loader that sends the secrets to the host
> 	   owner.
> 
> 	3. SVSM and attestation server have no way of detecting this,
> 	   because the disk image is not part of the initial measurement
> 	   from the SNP firmware. So above sequence would complete and
> 	   SVSM gets the secrets from the attestation server.
> 
> 	4. The malicious software loaded from the disk image gets access
> 	   to the secrets and sends them to the host owner.
> 
> 	4. Host owner can use the guest owners secrets to steal data
> 	   from the encrypted disk image the guest owner provided.
> 
> To prevent this it is necessary that the measurement sent to the
> attestation server includes all software and data which is
> executed/loaded from unencrypted storage. For example, in a common boot
> flow it needs to include the Grub binary and Grub configuration.
> 
> But these parts are not included in the initial measurement that the
> SVSM gets from the SNP firmware.

Aside from what James' says, one option is to lockdown the OVMF and
secureboot chain. eg OVMF built with SecureBoot=on, and instead of
having the generic Microsoft keys enrolled, have a distro specific
key enrolled. That distro key would have to be one that is only
used for signing UKIs (Unified Kernel Images), and the initrd embedded
in the UKI would need to be designed abort if it finds the disk is
not encrypted.

The main challenge here is that you don't have a single OVMF anymore.
You have many OVMFs, one for each distinct set of distro SecureBoot
keys, and the attestation server has to decide which one it wants
based on the distro the VM is expected to use.

If we don't do any of this, then the early attestation and secret
fetch would have to be limited to /only/ the secret for unlocking
the vTPM state, and not injected into the guest OS. The OS would
have to do everything else with the vTPM and PCR sealed data to
achieve the same end results of only getting access to secrets if
the vTPM sees the set of PCR values corresponding to the desired
UKI secureboot keys.

Ultimately the latter is probably the more common case and more
flexible.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|