Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option

[Cornelia Huck]

On Mon, 3 Aug 2020 18:14:57 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Mon, Aug 03, 2020 at 10:07:42AM +0200, Janosch Frank wrote:
> > On 8/3/20 9:54 AM, David Gibson wrote:  
> > > On Mon, Aug 03, 2020 at 09:49:42AM +0200, Janosch Frank wrote:  
> > >> On 7/24/20 4:57 AM, David Gibson wrote:  
> > >>> At least some s390 cpu models support "Protected Virtualization" (PV),
> > >>> a mechanism to protect guests from eavesdropping by a compromised
> > >>> hypervisor.
> > >>>
> > >>> This is similar in function to other mechanisms like AMD's SEV and
> > >>> POWER's PEF, which are controlled bythe "host-trust-limitation"
> > >>> machine option.  s390 is a slightly special case, because we already
> > >>> supported PV, simply by using a CPU model with the required feature
> > >>> (S390_FEAT_UNPACK).
> > >>>
> > >>> To integrate this with the option used by other platforms, we
> > >>> implement the following compromise:
> > >>>
> > >>>  - When the host-trust-limitation option is set, s390 will recognize
> > >>>    it, verify that the CPU can support PV (failing if not) and set
> > >>>    virtio default options necessary for encrypted or protected guests,
> > >>>    as on other platforms.  i.e. if host-trust-limitation is set, we
> > >>>    will either create a guest capable of entering PV mode, or fail
> > >>>    outright
> > >>>
> > >>>  - If host-trust-limitation is not set, guest's might still be able to
> > >>>    enter PV mode, if the CPU has the right model.  This may be a
> > >>>    little surprising, but shouldn't actually be harmful.  
> > >>
> > >> As I already explained, they have to continue to work without any change
> > >> to the VM's configuration.  
> > > 
> > > Yes.. that's what I'm saying will happen.
> > >   
> > >> Our users already expect PV to work without HTL. This feature is already
> > >> being used and the documentation has been online for a few months. I've
> > >> already heard enough complains because users found small errors in our
> > >> documentation. I'm not looking forward to complains because suddenly we
> > >> need to specify new command line arguments depending on the QEMU version.
> > >>
> > >> @Cornelia: QEMU is not my expertise, am I missing something here?  
> > > 
> > > What I'm saying here is that you don't need a new option.  I'm only
> > > suggesting we make the new option the preferred way for future
> > > upstream releases.  (the new option has the advantage that you *just*
> > > need to specify it, and any necessary virtio or other options to be
> > > compatible should be handled for you).
> > > 
> > > But existing configurations should work as is (I'm not sure they do
> > > with the current patch, because I'm not familiar with the s390 code
> > > and have no means to test PV, but that can be sorted out before
> > > merge).
> > >   
> > OK, should and might are two different things so I was a bit concerned.
> > That's fine then, thanks for the answer.  
> 
> Well, the "should" and "might" are covering different things.
> Existing working command lines should continue to work.  But those
> command lines must already have the necessary tweaks to make virtio
> work properly.  If you try to make a new command line for a PV guest
> with a virtio device - or anything else that introduces extra PV
> complications - then just chosing a CPU model with UNPACK might not be
> enough.  By contrast, if you set host-trust-limitation, then it should
> work and be PV capable with an arbitrary set of devices, or else fail
> immediately with a meaningful error.

Yes, that was also my understanding.

Getting the interaction with the cpu model right seems to be the tricky
part, though. The UNPACK feature would only be set automatically
_after_ the htl device has already checked for it...

pgpiiadwj_poa.pgp
Description: OpenPGP digital signature