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

[George Dunlap <george.dunlap@eu.citrix.com>]

On 06/03/2015 05:36 PM, Don Slutz wrote:
> 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@verizon.com>
>>> 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.

I agree with him that the emulator should be used to emulate the
instructions we *want* to emulate.  I'm just not happy with using the
emulator to emulate all the instructions we *don't* want to emulate
(i.e., all the ones that really do need to #GP).

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

I'm talking about cost-benefits analysis.  What's the benefit of
accepting this patch, and is it worth the cost?

My argument here is that the cost of this change is opening up a massive
attack surface on the Xen emulation code.

The benefit of this change: Allowing guest processes access to the
VMWare backdoor without guest OS cooperation.  (Guest OSes can access
the backdoor without this patch.)

I hadn't gotten to the part of the series where Qemu was roped in to do
mouse and clipboard stuff; so at the time I wrote that, the only
functionality that it looked like was being made available to the guest
was reading the clock and a couple of other random bits.

But I see I have another e-mail from Andy with information of material
importance to this discussion.

 -George