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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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)

~Andrew

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