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 > >
