Re: [Qemu-devel] [RFC PATCH v1 10/22] sev: add SEV debug decrypt command

[Michael S. Tsirkin]

On Wed, Sep 14, 2016 at 10:44:58PM +0200, Paolo Bonzini wrote:
> 
> 
> On 14/09/2016 22:36, Michael S. Tsirkin wrote:
> > Specifically with debug, if you have debug then clearly you
> > can dump guest memory. This is what this feature is about.
> > If we want a hypervisor that can not dump guest memory, let's
> > add a flag like that. Does everyone have to disable debugging
> > by default? I don't see why. Does everyone using encryption
> > have to do this? I don't see why either.
> 
> If you can explain what's the point in doing encryption that can be
> defeated with a single ioctl, perhaps I'll agree with you.

Discussed offline, I hope I clarified things.  Hypervisor (host kernel)
can decrypt but it is already possible for it to cause guest info leaks.
But no one else on the host can.

> It's okay
> that we leave out features.  But every feature left out is an
> anti-feature baked in.  Force-enable debug?  You've provided a loophole
> for everyone.

It's already baked in by default. Let's switch it to off by default for
everyone if we are worried about using monitor to leak guest secrets?
Btw with a TCP socket monitor, this seems like a legitimate worry.

We can do it when the new security policy object is created.

> Force-disable debug?  Well, of course you've blocked
> debug for everyone.
> 
> I agree that they are distinct features on the command line, but I think
> you're underestimating the importance of choosing a sane default, that's it.

We can safely leave that for management, but I won't object
to switching the default too, let's just do it for everyone,
consistently.

> >>  -object sev-policy-unencrypted,debug=false,id=mypolicy \
> >>  -machine ...,sev-policy=mypolicy
> > 
> > I wouldn't say sev on the command line. SEV seems to be
> > a group of AMD technologies implemening memory encryption,
> > measurement etc.
> > 
> > Let's have flags for individual components:
> > 
> > -machine ...,debug=false,memory-encryption=on,...
> 
> I think it makes sense to have a separate -object for the policy.  Let's
> just make it security-policy instead of sev-policy.  Brijesh, is that okay?
> 
> Paolo

OK. And some parts like blocking debug are easy enough to implement for 
everyone.

-- 
MST