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

[Don Slutz <dslutz@xxxxxxxxxxx>]

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>
X-Mailer: Novell GroupWise Internet Agent 14.0.1
Date: Mon, 26 Jan 2015 16:46:43 +0000
From: Jan Beulich <JBeulich@xxxxxxxx>
To: Don Slutz <dslutz@xxxxxxxxxxx>
CC: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>, Andrew Cooper
        <andrew.cooper3@xxxxxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>,
"George
 Dunlap" <George.Dunlap@xxxxxxxxxxxxx>, Ian Jackson
        <ian.jackson@xxxxxxxxxxxxx>, Stefano Stabellini
        <stefano.stabellini@xxxxxxxxxxxxx>, Eddie Dong <eddie.dong@xxxxxxxxx>, 
"Jun
 Nakajima" <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>,
        <xen-devel@xxxxxxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>,
        Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Keir Fraser 
<keir@xxxxxxx>,
        Tim Deegan <tim@xxxxxxx>
Subject: Re: [PATCH for-4.5 v8 4/7] xen: Add vmware_port support
References: <1412285417-19180-1-git-send-email-dslutz@xxxxxxxxxxx>
 <1412285417-19180-5-git-send-email-dslutz@xxxxxxxxxxx>
 <542DCA92.1030701@xxxxxxxxxxxxx> <542DD44F.6030101@xxxxxxxxxxxxx>
 <54B8F1740200007800055B42@xxxxxxxxxxxxxxxxxxxx>
 <54BFE768.3090309@xxxxxxxxxxxxx>
 <54C0C39F0200007800057F73@xxxxxxxxxxxxxxxxxxxx> <54C6643B.1@xxxxxxxxxxxxx>
In-Reply-To: <54C6643B.1@xxxxxxxxxxxxx>

   -Don Slutz

>  -George
> 

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