Re: SVSM initiated early attestation / guest secrets injection

[James Bottomley <jejb@linux.ibm.com>]

On Thu, 2023-01-19 at 15:05 +0100, Christophe de Dinechin Dupont de
Dinechin wrote:
> 
> 
> > On 13 Jan 2023, at 19:02, James Bottomley <jejb@linux.ibm.com>
> > wrote:
> > 
> > On Fri, 2023-01-13 at 18:22 +0100, Jörg Rödel wrote:
> > [...]
> > >         2. Host owner attaches a different disk image with
> > > malicious content, e.g. a boot loader that sends the secrets to
> > > the host owner.
> > 
> > 
> > This attack was discussed in the initial encrypted image prototype
> > for SEV and SEV-ES.  The idea is that either the disk is encrypted
> > with the injected encryption key (i.e. decodes correctly) or it
> > isn't, in which case it's up to the mounting component (grub in the
> > initial prototype and initrd in this proposal) to declare failure
> > and destroy the secrets.
> 
> However, I recall discussions about the possibility that the host
> owner could trigger a fallback back that mounts an *unencrypted*
> disk successfully (or even discovers it). I remember discussions
> on such cases with Daniel (about auto-discovery of boot partitions)
> and Gerd (about fallback path for “compatibility” reasons).
> 
> So I believe that we need to clarify how we prevent the discovery
> and mounting of non-encrypted partitions, no?

Yes, you have to think about this.  Possessing the secrets is the
problem if you don't trust what you've mounted, so in the original
prototype the secrets got destroyed if they weren't used (as in you
couldn't crypto mount the disk), so you can fallback to a potentially
untrusted disk if you can ensure the secrets can't be leaked.  I
suppose secret destruction and fallback should be a configurable policy
of the system instead of hard coded as I did in the initial prototype.

James