Re: [Qemu-devel] [RFC PATCH v2 06/16] sev: add Secure Encrypted Virtulization (SEV) support

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Sep 22, 2016 at 04:12:04PM -0500, Brijesh Singh wrote:
> Hi,
> 
> On 09/22/2016 10:12 AM, Paolo Bonzini wrote:
> > 
> > 
> > > 
> > >   to use encrypted guest launch
> > >   # $QEMU \
> > >      -object sev-receive-info,id=launch0 \
> > >      -object sev-send-info,id=send0 \
> > >      -object sev-guest-info,id=sev0,launch=launch0,send=send0 \
> > >      .....
> > > 
> > 
> > References to other objects should be implemented as link properties
> > (e.g. with type 'link<sev-guest-info>').  Then QOM takes care of filling
> > in a QSEVGuestInfo* with the pointer to an object with the right id.
> > 
> > There is some redundancy (e.g. "flags.ks" in launch/receive vs. "ks" in
> > policy).  Can you document the full model in
> > docs/amd-memory-encryption.txt?  It's not necessary to include the
> > kernel API documentation.
> > 
> 
> The flags.ks means that hypervisor requested the key-sharing. The policy.ks
> means that key-sharing is allowed by guest owner. The values in sev-policy
> should be provided by the guest owner. The content of policy field is used
> during the measurement calculation.

We excluded the measurement part for now, so I think this can
go as well.

> If hypervisor changes anything into
> policy field without guest owners permission then measurement value will not
> match.

IMHO measurement is mostly useless with current hardware.

I suggest that for now we just assume that hypervisor is not
attacking the guest while it's booting.
Extend this later once first part is merged.

> I can think of one case where flag.ks may be used.
> 
> e.g lets say guest policy allows key sharing and this is first SEV guest in
> the system then hypervisor will set flags.ks=0. In next guest launch it can
> set flags.ks=1 and use the SEV handle from previous guest.
>
> I will add some more text to clarify it in doc and property description.
> 
> > Paolo
> >