William Pitcock, le Sun 10 Feb 2008 06:56:59 -0600, a écrit : > On Sun, 2008-02-10 at 13:32 +0100, Bastian Blank wrote: > > You have to show evidence that the Hypervisor crashed if the exploit > > runs in a domU. dom0 is special and can always crash the hypervisor. A > > stacktrace is usable to do this. > > However, running the exploit does indeed cause the hypervisor to crash;
Again, that's no wonder for a dom0, but the question is "what about domU". > The exploit works by altering the memory map (via vmsplice()) to get > access into kernel space. Yes, and in such case Xen will refuse to make the memory map change and just crash the guest. > Since the memory map is altered in the domU, it is no longer in sync > with the global state. What do you call "global state"? > Each domU is aware of the state of the other domU's ?! domUs don't know each other. > in Xen (at least, this is what the documentation tells me, What part of the documentation brings you to that? > ). If one domU gets out of sync, it could cause state corruption in > the hypervisor. There's no reason why a domU should be in charge of keeping in sync. In the security model of Xen, domU is _not_ trusted. > As a result, Xen should check for this state corruption by maintaining > a secondary copy of the memory map and ensuring that it has not been > altered. If it has been altered, it should _probably_ kill the VM > which did it. It already traps and checks _all_ updates of the memory maps and kills the VM if appropriate (but lets dom0 do whatever it wants). Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
