[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v11 6/9] xen: Add ring 3 vmware_port support
On 03/06/15 16:26, George Dunlap wrote: > On 05/22/2015 04:50 PM, Don Slutz wrote: >> Summary is that VMware treats "in (%dx),%eax" (or "out %eax,(%dx)") >> to port 0x5658 specially. Note: since many operations return data >> in EAX, "in (%dx),%eax" is the one to use. The other lengths like >> "in (%dx),%al" will still do things, only AL part of EAX will be >> changed. For "out %eax,(%dx)" of all lengths, EAX will remain >> unchanged. >> >> This instruction is allowed to be used from ring 3. To >> support this the vmexit for GP needs to be enabled. I have not >> fully tested that nested HVM is doing the right thing for this. >> >> Enable no-fault of pio in x86_emulate for VMware port >> >> Also adjust the emulation registers after doing a VMware >> backdoor operation. >> >> Add new routine hvm_emulate_one_gp() to be used by the #GP fault >> handler. >> >> Some of the best info is at: >> >> https://sites.google.com/site/chitchatvmback/backdoor >> >> Signed-off-by: Don Slutz <dslutz@xxxxxxxxxxx> > So let me get this straight. > > VMWare allows ring3 to access the magic port regardless of whether the > guest OS has enabled access to that IO port or not. > > In order to emulate this, we need to: > * Trap to Xen on #GPs rather than just letting the hardware handle it > * Emulate all instructions which cause a #GP, just to see if they might > be an IO instruction accessing the magic port. > * If it is an IO instruction, and it's accessing the magic port, then we > skip the ioport access checks (which will cause the instruction to > execute as though it had been given access). > * Under all other circumstances (we hope) the emulator in Xen will do > exactly what the hardware just did, and deliver a #GP to the guest. > > In an attempt to make this more safe, emulation ops that write (such as > write and cmpxchg) are replaced with stubs which always return an error. > > Is that about right? > > That sounds completely insane. It opens up an almost infinite surface > of attack onto the Xen emulator. > > I understand that having the "VMWare compatible" is a nice tick-box to > have, but seriously, I cannot imagine that having unprivileged > user-space tools know the real clock frequency without having to involve > the OS is anywhere close to worth the risk involved. The attack surface sadly is not enlarged in the slightest by this change. We already trap and emulate all #UD exceptions in an attempt to support migration of VMs between Intel and AMD hardware. See XSA-105. (There is a good argument to be made for not trapping #UD, but that doesn't completely close the hole) ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |