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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.06.15 at 18:50, <george.dunlap@xxxxxxxxxxxxx> wrote:
> 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@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.
> 
> 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).

And hence the suggestion to stub out hooks that shouldn't get
involved. Of course us running into the problem of wanting to limit
what gets emulated now the second or third time perhaps we
should rather consider an extension to the emulator interface that
callers can use to control what kinds of operations it wants
emulated (with anything else causing failure) - in the case here,
I/O instructions.

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

The basic idea of allowing guests originally having got installed on
VMware to continue their lives on Xen is certainly something worth
accepting some cost. It's really hard to judge whether in the case
here things go too far (and that would equally apply to the hand
crafted instruction decoding done in earlier versions of this series).

Jan

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