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

[Don Slutz <dslutz@xxxxxxxxxxx>]

On 10/02/14 06:05, Tim Deegan wrote:
> At 16:00 -0400 on 26 Sep (1411743641), Don Slutz wrote:
> > On 09/25/14 06:37, Tim Deegan wrote:
> > > At 17:18 +0100 on 22 Sep (1411402700), Jan Beulich wrote:
> > > > > > > On 22.09.14 at 17:38, <george.dunlap@xxxxxxxxxxxxx> 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.
> That needs to be fixed somewhere.  If Xen/Qemu is going to provide
> this interface it _must_ copy the privilege checks, even if we don't
> understand why they're there -- in fact, _especially_ if we don't
> understand why they're there! :)
>
> If the third-party header file isn't a reliable source, you'll have to
> determine the correct behaviour by experiment.
I have done this.  Will be adding the check.

> > 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.
> I strongly disagree with this.  If our implementation of this
> interface makes guest OSes less secure than they would be under actual
> VMware then the config option is irrelevant.
Ok.

   -Don Slutz

> Cheers,
>
> Tim.

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