Re: [Qemu-devel] [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object

[Eduardo Habkost]

On Thu, Mar 08, 2018 at 04:22:52PM -0600, Brijesh Singh wrote:
> 
> 
> On 3/8/18 10:49 AM, Daniel P. Berrangé wrote:
> > On Thu, Mar 08, 2018 at 06:48:41AM -0600, Brijesh Singh wrote:
> >> Add a new memory encryption object 'sev-guest'. The object will be used
> >> to create enrypted VMs on AMD EPYC CPU. The object provides the properties
> >> to pass guest owner's public Diffie-hellman key, guest policy and session
> >> information required to create the memory encryption context within the
> >> SEV firmware.
> >>
> >> e.g to launch SEV guest
> >>  # $QEMU \
> >>     -object sev-guest,id=sev0 \
> >>     -machine ....,memory-encryption=sev0
> >>
> >> Cc: Paolo Bonzini <address@hidden>
> >> Cc: Richard Henderson <address@hidden>
> >> Cc: Eduardo Habkost <address@hidden>
> >> Signed-off-by: Brijesh Singh <address@hidden>
> >
> >> diff --git a/qemu-options.hx b/qemu-options.hx
> >> index 4c280142c52c..6113bce08a8c 100644
> >> --- a/qemu-options.hx
> >> +++ b/qemu-options.hx
> >> @@ -4353,6 +4353,50 @@ contents of @code{iv.b64} to the second secret
> >>           data=$SECRET,iv=$(<iv.b64)
> >>  @end example
> >>  
> >> address@hidden -object 
> >> sev-guest,address@hidden,address@hidden,address@hidden,address@hidden,address@hidden,address@hidden,address@hidden,address@hidden
> >> +
> >> +Create a Secure Encrypted Virtualization (SEV) guest object, which can be 
> >> used
> >> +to provide the guest memory encryption support on AMD processors.
> >> +
> >> +When memory encryption is enabled, one of the physical address bit (aka 
> >> the
> >> +C-bit) is utilized to mark if a memory page is protected. The 
> >> @option{cbitpos}
> >> +is used to provide the C-bit position. The C-bit position is Host family 
> >> dependent
> >> +hence user must provide this value. On EPYC, the value should be 47.
> >> +
> >> +When memory encryption is enabled, we loose certain bits in physical 
> >> address space.
> >> +The @option{reduced-phys-bits} is used to provide the number of bits we 
> >> loose in
> >> +physical address space. Similar to C-bit, the value is Host family 
> >> dependent.
> >> +On EPYC, the value should be 5.
> > Is it valid to specify a different value for either of these properties ?
> > eg what happens if I pass cbitpos=45 instead of 47 on an EPYC host ?
> 
> On EPYC, passing anything other than 47 will trigger error during SEV
> guest initialization. The value of Cbit position is host dependent, the
> value is readonly and can be obtained through the host CPUID.  The
> cbitpos must be same between guest and host. Please note that the pte's
> in guest page table will need to use the cbitpos  information to mark
> the pages as encrypted. If cbit position given to the guest is different
> from the host then guest will fail to execute.
> 
> >
> > In particular I thinking about possible migration scenario, where EPYC
> > uses 47 by default but some $NEXT AMD CPU uses 48 by default. In that
> > case we might want to use '47' on both CPUs if we need ability to live
> > migrate between different host CPU generations. Would that be valid ?
> 
> We will not be able to migrate SEV guests if cbit position does not
> match between the source and destination hosts. Since during migration,
> the destination guest is launched with same QEMU cli as source hence
> cbitpos check in QEMU will catch it and fail the new launch. Optionally,
> user can call query-sev-capabilities on both source and destination to
> see if cbitpos is compatible before attempting to migrate the guest.
> 
> > On the flip side, if the value really it strictly tied to the host
> > CPU family and no deviation is permitted, could the kernel not just
> > pick the right value automatically avoiding the config option ?
> >
> 
> I think doing so will be an issue for the migration. Consider your above
> use case, a SEV guest is running on EPYC with cbitpos=47 and if we
> migrate to some $NEXT AMD CPU which uses need to use cbitpos=48 and we
> will fail to resume the guest on destination after migrating.

Exactly, in other words these two options are part of the guest
ABI, and QEMU promises to never make the guest ABI depend on the
host hardware unless you're using "-cpu host".

In theory we could make QEMU choose the right values
automatically if we document very clearly that the default
behavior is unsafe.  But I would rather not take that risk and
force management software to be aware of the gotchas involved in
using SEV + live-migration.

-- 
Eduardo