On Wed, Sep 14, 2016 at 06:53:22PM +0200, Paolo Bonzini wrote: > > > On 14/09/2016 17:02, Michael S. Tsirkin wrote: > > If you believe there are attackers that have access to the > > monitor and nothing else, then a feature to disable debugging > > is a generally useful one. But once we merge sev patchset then of course > > sev people disappear and it will be up to others to make it > > work on non-amd CPUs. > > > > Another is to help merge other parts faster. E.g. looking at what > > Daniel writes, the feature might have been over-sold so people will > > disable debugging thinking this will prevent all active attacks. Thus we > > now need to add good documentation so people know what they can actually > > expect to get from QEMU in return for disabling debugging. Why not merge > > the simple "encrypt memory part" while this documentation work is going > > on? > > Encrypting memory makes no sense if anyone can ask to decrypt it.
It's not useless since the attack model here is a passive adversary that can not ask anything. > And > I'm not even sure how force-enabling debug r/w, which is literally a > single bit set in the feature register, would make the patchset simpler. It will make the *interface* simpler. > If anything, as I said already, it would make the patchset simpler to > force-*disable* it, since you don't need to introduce debug hooks that > go through the secure processor. > > Paolo My suggestion is to add a processor independent hook that disables debugging. Arguably this improves security in case attacker only has access to the monitor. -- MST
