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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Sep 14, 2016 at 09:58:25PM +0200, Paolo Bonzini wrote:
> 
> 
> On 14/09/2016 21:24, Michael S. Tsirkin wrote:
> > Well limited protection is of a limited use :) Seriously, the point of
> > mitigation should be blocking classes of vulenrabilities not making
> > things more complex.
> 
> No, not at all.  The point of _mitigation_ is to _mitigate_ the danger
> from classes of vulnerabilities, i.e. make the attack harder though
> perhaps not ultimately impossible.

Right. And features generally reduce security. Does not mean we don't
need to add any features.  The tradeoffs need to be weighted and
documented, this is missing here.

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 the adversary is passive and cannot ask anything is it even an
> >> adversary?  Why do you need encryption at all if you can't even ptrace QEMU?
> > 
> > The cover letter mentioned a read everything adversary.
> > How do you read everything? Well, you probably don't but
> > there could be attacks that cause kernel to leak
> > contents of random memory to an attacker.
> 
> Ok, it doesn't seem too useful.
> 
> > On the software side, we should try to
> > push for enabling features independently, this way more
> > hardware can benefit.
> 
> We can have an "unencrypted" sev-policy that only has limited
> functionality such as disabling debug.  So you could disable debug with
> 
>  -object sev-policy-unencrypted,debug=false,id=mypolicy \
>  -machine ...,sev-policy=mypolicy
> 
> Paolo

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

E.g. I can imagine tcg implementing encrypted at rest memory.

If you are on AMD and memory=encrypted then you would enable
SEV. If debug=false then disable debug. As I mentioned,
if monitor is a socket this might be genuinely increasing
guest security.

I'm fine with e.g. memory-encryption=on being an AMD-only
feature for now.

-- 
MST