[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v11 6/9] xen: Add ring 3 vmware_port support
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |