On 09/14/2016 03:44 PM, 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. 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?
Yes, fine with me.
-Brijesh
