Re: [Xen-devel] [PATCH for-4.5 v6 00/16] Xen VMware tools support

["Slutz, Donald Christopher" <dslutz@xxxxxxxxxxx>]

On 09/30/14 06:09, George Dunlap wrote:
> On 09/30/2014 12:13 AM, Don Slutz wrote:
>> On 09/29/14 09:27, George Dunlap wrote:
>>> On 09/29/2014 07:50 AM, Jan Beulich wrote:
>>>>>>> On 26.09.14 at 22:00, <dslutz@xxxxxxxxxxx> wrote:
>>>>> On 09/25/14 06:37, Tim Deegan wrote:
>>>>>> At 17:18 +0100 on 22 Sep (1411402700), Jan Beulich wrote:
>>>>>>> That's indeed what was said so far. I wonder though whether opening
>>>>>>> this up without guest OS consent isn't gong to introduce a security
>>>>>>> issue inside the guest (depending on the exact functionality of 
>>>>>>> these
>>>>>>> hypercalls).
>>>>>> Yes indeed.  VMware seems to have CPL checks on some of the commands
>>>>>> (but not all).  I guess Xen will be no worse than VMware if we do 
>>>>>> the
>>>>>> same, though I'd like to have an official spec to follow for that.
>>>>> Yes, VMware has CPL checks on some of the commands.  Not at all
>>>>> clear the include file has the correct statement.  I have not do any
>>>>> checking of CPL nor does QEMU.  And the RPC (which is CPL 3) is
>>>>> one of the most likely to have a security issue.
>>>>>
>>>>> I do not know of an official spec to follow.  The best I have the
>>>>> the provided include file and testing on VMware.
>>>>>
>>>>> I do know that BDOOR_CMD_GETHZ is one that is not allowed in
>>>>> ring 3, but this makes no sense to me.  I do not see why tsc_freq
>>>>> and apic bus speed to be things to hide.  And VMware is not
>>>>> consistent.  On newer configs this same info is available via
>>>>> cpuid leaf in ring 3.
>>>>>
>>>>> Also I have not idea if VMware did the CPL checking "correctly".
>>>>> I.E. is a #GP => CPL 3, or do they check CPL?
>>>>>
>>>>> All this leads to I current do not check CPL on any VMware commands.
>>>>>
>>>>> I could look into doing this, but with the xl.cfg flag vmware_port=0
>>>>> turns this all off, I do not see any need for CPL checking.
>>>> Hmm, I think we need to settle on certain things here:
>>>> a) I don't think it is okay to base our emulation layer entirely
>>>> on observed behavior. At least some form of specification should
>>>> be there to follow. This is both for reviewing the code you want
>>>> committed and maintainability.
>>>
>>> While that would be nice, I think that's unlikely; and overall I 
>>> think it would be better to have a reverse-engineered implementation 
>>> than no implementation at all.  Having a reverse-engineered spec 
>>> might be a good idea though.
>>>
>>
>> I could work on a reverse-engineered spec.  Is having this on the wiki
>> good enough or does it need to be in the code?
>>
>> There is a old but useful web page:
>>
>> https://sites.google.com/site/chitchatvmback/backdoor
>>
>> Which is basicly the start of a reverse-engineered spec.
>>
>> Since I am not proposing to implement all the listed commands
>> on that web page, I could see some use in listing the currently
>> supported VMware backdoor commands.
>>
>>>> b) I don't think it is okay to introduce security issues into a guest
>>>> even if that is something that isn't enabled by default.
>>>
>>> I agree with this; in particular, it's quite possible that someone 
>>> will decide to enable VMWare functionality by default, "just in 
>>> case", and then forget that they've done so.
>>>
>>
>> I am assuming that the phrase "security issues" is used as a
>> reference to things like http://xenbits.xen.org/xsa/ or
>> http://wiki.xen.org/wiki/Securing_Xen.
>>
>> Or as it might be stated -- A way to cause a guest to crash or have
>> a DoS (/Denial of Service) or a way in from outside (like "/SMASH the
>> Bash bug".
>>
>>
>> But not the area of
>> http://en.wikipedia.org/wiki/Rainbow_Series or
>> http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria
>>
>> Which talks about "Covert Channel Analysis" and other complex
>> security issues. (like *"Evaluation Assurance Level", **"Trusted 
>> Computer System Evaluation Criteria", etc.)*
>>
>>
>> I feel it is "safe" to run all guests with vmware_port=1 and
>> vmware_hw=7.  However I am not stating that all guests function
>> the same with just this.  I do know that xen_platform_pci=0
>> may also need to be specified to get expected results.
>>
>> I also do not understand the statement "enable VMWare functionality by
>> default".  I must be missing something because as far as I know each
>> guest (domU) has it's own config.  Is this a xl tool stack feature (some
>> common config for guests)? Or is it some other tool stack feature?
>>
>>
>>>> c) Apparent or real flaws with VMware's native implementation
>>>> should be brought up with VMware. While mimicking their behavior
>>>> as closely as possible is certainly a desirable goal, reproducing
>>>> flaws their code has should imo be avoided if at all possible.
>>>
>>> If our goal is compatibility with exiting tools, is there really 
>>> such a thing as "reproducing flaws"?  Obviously we shouldn't 
>>> reproduce a real security flaw, but for everything else, if the 
>>> feature is "Looks just like VMWare", then being as close as possible 
>>> in behavior is the ideal.
>>>
>>
>> I can agree that is it ideal.  However getting to this ideal place 
>> can have
>> a high cost.  Case in point "BDOOR_CMD_GETHZ".  The VMware provided
>> include file has no CPL comments.  The same include file in "open vm
>> tools" does, but not for BDOOR_CMD_GETHZ.  However a VMware
>> test system does different things for ring 0 (aka a Linux kernel module)
>> and ring 3.  Neither one report a fault, but the ring 3 one does not
>> return any data.  I do not know that the result is if I enable ring 3 
>> I/O
>> via the TSS (since I do not know of a simple way to do that). If I 
>> change
>> IOPL then it still hides information.
>>
>> Now there is also the "BDOOR_CMD_GETMHZ".  It also has no CPL
>> statement but does return the tsc_freq in MHZ.  So why is tsc_freq
>> in HZ considered sensitive information, but in MHZ it is not?
>>
>> Just to confuse this more, for vmware_hw=7, cpuid leave 0x40000010
>> has tsc_freq in KHZ.  So again why is tsc_freq in HZ special?
>>
>> How about the comment on other commands "/* CPL 0 only. */"
>> which appears to apply here, but the comment is missing.  So
>> do I check the segment register SS's DPL (what I know of as CPL),
>> or is it the segment register CS's DPL (which has been mistakenly called
>> CPL by some programs)?  Or is it something else which VMware has
>> decided to mean "ring 3"?
>>
>>
>> Based on all this, and since I do not see how tsc_freq in HZ could be
>> a "real security flaw", I do not see a reason to spend a lot of time
>> attempting to reverse engineer this strange behavior.
>>
>> I am not saying that I would not add some type of check for "ring 3"
>> for this one command, but I do not see a good reason for it. The only
>> case I could see is that it is one of many ways to determine that you
>> are running under Xen and not VMware.
>
> Sure; the actual "feature" is for VMWare tools to work as expected 
> within the guest.  Having the behavior be exactly the same as VMWare 
> is one way of making sure those tools work; the amount of time you 
> spend duplicating the exact behavior vs just making sure the tools 
> work as expected is a sort of cost/benefits analysis.
>

Yes.  What I was trying to say (and was not clear I guess) is that there is
no simple way to test for a lot of the corner functionality.  Since the 
VMware
tools have a large part that runs in ring 3, they do not use this backdoor
command.  So I saw a cost in adding a check and an almost 0 benefit,
and went with the cheap way.

> The main risk of deviating from VMWare is if there are corners of the 
> tool functionality you don't test, or if VMWare updates their tools 
> and the new version is compatible with old VMWare hypervisors but not 
> old Xen hypervisors.
>

Yes.  I have added a check for the 1 command that has different actions
based on "dpl of ss" == 0 (which is all that I have tested on VMware).  
So the
next version will be even closer.

     -Don Slutz

>  -George

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