[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


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

I fully agree that *we* need to be thinking carefully about the 
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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.