Re: [Xen-devel] [PATCH v11 6/9] xen: Add ring 3 vmware_port support

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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