From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnBzy-0000TK-2Q for qemu-devel@nongnu.org; Thu, 22 Sep 2016 17:57:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bnBzt-0000tg-Vl for qemu-devel@nongnu.org; Thu, 22 Sep 2016 17:57:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58088) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnBzt-0000tG-Pf for qemu-devel@nongnu.org; Thu, 22 Sep 2016 17:57:37 -0400 Date: Fri, 23 Sep 2016 00:57:34 +0300 From: "Michael S. Tsirkin" Message-ID: <20160923005204-mutt-send-email-mst@kernel.org> References: <147455590865.8519.11191009507297313736.stgit@brijesh-build-machine> <147455596937.8519.6403549430047219068.stgit@brijesh-build-machine> <69f9cab5-e2dd-0461-8857-64cfa4bb7e8e@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC PATCH v2 06/16] sev: add Secure Encrypted Virtulization (SEV) support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Brijesh Singh Cc: Paolo Bonzini , ehabkost@redhat.com, crosthwaite.peter@gmail.com, armbru@redhat.com, p.fedin@samsung.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, rth@twiddle.net 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'). 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 > >