On Wed, Sep 14, 2016 at 04:14:04PM +0200, Paolo Bonzini wrote: > > > On 14/09/2016 16:08, Eduardo Habkost wrote: > >> > If attacker can trigger things, IOW execute code in hypervisor, > >> > then encrypting memory is not useful anyway. > > I believe the whole point of SEV attestation and key management > > is to make "if attacker can executed code in hypervisor, > > encrypting memory is not useful" _not_ true, isn't it? > > > > Or are there known vulnerabilities that would allow a compromised > > hypervisor to decrypt memory even after successful > > encryption+attestation? > > There are countless side channels that you can use but you have to start > somewhere,
Absolutely, so let's start with a feature that is orthogonal, has a defined threat model and does not conflict with valid uses please. I was very happy to see an actual threat documented (passive adversary with read only capabilities) as opposed to a vague makes some attacks harder. Why don't we merge a patchset with that, and then add stuff on top, documenting the benefits at each step? > and anyway a side channel attack is way way more complex More complex, sure, but in the age of libraries of exploits, I'm not convinced it is measureably *harder* even if you add a third "way" in this sentence. 0 multiplied by 1000 is still 0. > than > just "trigger a debug dump and read it". > > Paolo Really, my point isn't that ability to disable debugging is useless. My point is that the feature is not really related to memory encryption except by the vague "both are security things" notion. If you consider adversary that has access to the monitor and nothing else, then apparently disabling dumps and debugging might be useful. So don't tie it all in to SEV please. -- MST
