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

[Don Slutz <don.slutz@xxxxxxxxx>]

On 06/03/15 11:58, 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?

Yes, however it is missing that Jan Beulich wanted the emulator in Xen
to be used.  I had started with code that did not use the emulator.

>> 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.

Not sure how you moved from attack surface to "real clock frequency"
(which I am not sure which of the many "clock frequency" you are
referring to.  The only new one that leaps to mind is the emulated lapic
bus frequency (which Linux attempts to determine from other clocks).

> 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)

Ah, thanks, I did not know this fact.

   -Don Slutz

>
> ~Andrew
>
> _______________________________________________
> 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