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

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

On 09/30/14 06:02, George Dunlap wrote:
> On 09/30/2014 08:05 AM, Jan Beulich wrote:
>>>>> On 30.09.14 at 01:13, <dslutz@xxxxxxxxxxx> wrote:
>>> On 09/29/14 09:27, George Dunlap wrote:
>>>> On 09/29/2014 07:50 AM, Jan Beulich wrote:
>>>>> 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?
>> I don't think the place it's at matters that much. All that does matter
>> is if it's something outside of our control, it should be a place that
>> reasonably certainly won't go away any time soon, so that a link
>> placed somewhere in our tree won't become stale.
>
> I think long term it would make sense to have a document in-tree that 
> describes what the code is trying to do.
>

Ok.

>>
>>>>> 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.)*
>> Covert channels are consider security issues too when applying
>> strict criteria. But the main concern here are indeed ways for guest
>> user mode to badly affect the guest as a whole (or the host, but I
>> think that should really go without saying).
>
> Just to bring home the point -- this code makes it so that some 
> instructions, namely IO instructions, running with no privilege checks 
> in ring 3, can access certain extra bits of potentially arbitrarily 
> complicated "virtual hardware" functionality which the OS doesn't know 
> anything about and has no way to contain or prevent.  This opens up 
> the possibility that there's a bug in the functionality somehow 
> (either in how VMWare implements it, or how we implement it) which an 
> attacker can leverage to gain privileges within the guest.
>
> I think Jan's point is that *we* need to be thinking carefully about 
> the functionality itself, and how we implement it, to make sure (as 
> far as we are able) that we don't introduce such a vulnerability. 
> Saying "this is the observed functionality of VMWare" isn't enough, 
> because, well, they're not perfect. :-)
>

Well, now that the VMware "RPC" has been moved to QEMU (which does
add a new dimension to this), what is left is not that complex.  It add 
8 ways
to get "hypervisor" info; and one that sets eax (rax) to 0.  So I am 
sure that
all this code does not enable any gains of privileges within the guest.  
It might
add a covert channel, but that is not how you gain privileges within the 
guest.

I fully agree that *we* need to be thinking carefully about the 
functionality.
And none of my statements about the security depend on the observed
functionality of VMware, they are all about the code posted here.

>>> 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?
>> Higher layer management tools may choose to create guest configs
>> that have certain settings always enabled (like at least used to be
>> the case in XenServer for the Viridian flag - not sure if that got
>> changed -, i.e. enabling this even for non-Windows guests, which
>> caused issues with Linux).
>
> Or "vmware_hw=7" gets into a "howto" on the internet and mindlessly 
> copied.  Or a template which is then cloned over and over again 
> without checking.  Don't vmdk's include some guest configuration as 
> well?  Or as Jan said, XenServer or OpenStack or CloudStack or 
> XenOrchestra or oVirt set it as a default, because it can't hurt, right?
>

vmdk's can have guest configuration (not sure how that fits in).
I have attempted to avoid saying "vmware_hw=7" cannot hurt.  I know that
people can write code that does bad things.  To follow on your example
(as I understand it) Linux had an issue with Viridian and Xen being on
at the same time and there were Viridian features missing (or just a 
code path
that was not tested).  However I am confident that enabling these 
features will
not add new security issues at this time.  I have no issue with stating: 
"Do not
mindlessly set either vmware_hw or vmware_port".

    -Don Slutz



>  -George

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