[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 06/03/2015 05:40 PM, Andrew Cooper wrote: > On 03/06/15 17:23, George Dunlap wrote: >> On 06/03/2015 04:58 PM, Andrew Cooper wrote: >>> 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) >> So at the moment, an attacker on Intel can force the emulation of any >> AMD-only instruction (and vice versa), is that right? >> >> This would allow an attacker to force the emulation of every #GP >> condition of every instruction we emulate. >> >> Those two sets may be within an order of magnitude of each other, but >> they will only overlap a little bit. So my guess is that enabling this >> would double the surface of attack (give or take). >> >> I'd be a lot happier with this patch if we could make it so that on a >> #GP the only instruction that could get emulated would be an IO instruction. > > Any multi-threaded guest (userspace even) can force any arbitrary > instruction through the emulator. *grumble grumble* > If there is anything we currently mis-emulate #GP wise, it is already a > issue and enabling #GP intercepts doesn't make the hole any bigger. I still really don't like it. It's not just flipping a bit and then doing what we did before. You want to take bets as to whether this will be involved in an XSA sometime in the next 5 years? :-) -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |