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. 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. 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. >> -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
