On Thu, Sep 22, 2016 at 04:12:04PM -0500, Brijesh Singh wrote:
> 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
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