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

[Don Slutz <don.slutz@xxxxxxxxx>]

On 06/03/15 12:58, George Dunlap wrote:
> On 06/03/2015 05:41 PM, Don Slutz wrote:
>> On 06/03/15 12: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.
>>>
>>
>> You mean like I said in:
>>
>>
>> Message-ID: <54C67D8302000078000598E4@xxxxxxxxxxxxxxxxxxxx>
> 
> Yes, pretty much exactly.
> 
> I didn't notice that particular part of the discussion, but I did go
> back and skim the comments that people had made on previous revisions,
> and I certainly noticed that both Jan and Andy reviewed this patch, and
> that neither one objected to the general idea.  So my "That sounds
> insane" was as much directed at them as at you.
> 
> (As an aside, I think my description does a better job of alerting a
> reviewer to what's going on in this patch -- you might consider stealing
> part of it if you end up re-submitting this one.)
> 

I would be happy to "steal" the description part.  I normally give
credit to the author in the "what has changed".  I could also add to the
commit message:


George Dunlap summarized this change as:

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.


   -Don Slutz

>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel