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

[Don Slutz <dslutz@xxxxxxxxxxx>]

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.

   -Don Slutz

>  -George

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