qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [RFC PATCH v1 10/22] sev: add SEV debug decrypt command
Date: Thu, 15 Sep 2016 11:58:30 -0300
User-agent: Mutt/1.7.0 (2016-08-17)

On Thu, Sep 15, 2016 at 01:05:12AM +0300, Michael S. Tsirkin wrote:
[...]
> > > Attestation seems mostly unrelated. The whitepaper says
> > >   With this attestation, a guest owner can ensure that the hypervisor did
> > >   not interfere with the initialization of SEV before transmitting
> > >   confidential information to the guest.
> > > which seems to imply an active attacker that is able to interfere
> > > with the hypervisor during guest initialization but not afterwards.
> > 
> > I believe this assumes a compromised hypervisor both before and
> > after guest launch, but this assumes the hypervisor:
> > 1) Won't be able to change guest memory before attestation
> >    without being detected.
> > 2) Won't be able to attack the guest after memory is encrypted.
> 
> Why would you need to measure things then?  If you assume this, at what
> point *can* attacker change memory?

I am assuming an attacker that can change memory at any moment.
If memory is changed before encryption, measurement/attestation
would detect it. And I assume that memory changes after
encryption won't cause much damage except crashing the guest.

> 
> > > So I have no idea why that's useful at the moment - I suspect
> > > it's part of the future vision when there are protections
> > > against all active attackers in place, but for now it seems to extend the
> > > firmware/software interface unnecessarily.
> > 
> > "Protection against all active attackers" is a very broad
> > requirement. Effective protection against a given subset of
> > attacks would be reasonable enough to me.
> 
> Well selecting a random point in time and saying "I protect against
> attacks at this point only" would be a very weak protection, akin to
> just adding an assert statement at a random place in code - even though
> yes, if you hit that assert you are protected.
> 
> This is not to say this is what this patchset does, merely
> that it should include a bit more information about the
> motivation for the measurement part than
> "this is what we can easily implement".

Agreed that we need more information about the attacks they have
in mind.

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]