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
