From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH for-4.5 v6 00/16] Xen VMware tools support Date: Fri, 26 Sep 2014 16:00:41 -0400 Message-ID: <5425C5E9.6010102@terremark.com> References: <1411236447-7435-1-git-send-email-dslutz@verizon.com> <1411394209.18331.113.camel@kazak.uk.xensource.com> <54203DE9.9040307@eu.citrix.com> <1411400048.26552.10.camel@kazak.uk.xensource.com> <54204280.2030408@eu.citrix.com> <542067EC020000780003731E@mail.emea.novell.com> <20140925103712.GA92778@deinos.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140925103712.GA92778@deinos.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan , Jan Beulich Cc: Ian Jackson , Kevin Tian , Keir Fraser , Ian Campbell , Stefano Stabellini , George Dunlap , Andrew Cooper , Eddie Dong , Don Slutz , xen-devel@lists.xen.org, AravindGopalakrishnan , Jun Nakajima , Boris Ostrovsky , Suravee Suthikulpanit List-Id: xen-devel@lists.xenproject.org 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, wrote: >>> On 09/22/2014 04:34 PM, Ian Campbell wrote: >>>> On Mon, 2014-09-22 at 16:19 +0100, George Dunlap wrote: >>>>> On 09/22/2014 02:56 PM, Ian Campbell wrote: >>>>>> On Sat, 2014-09-20 at 14:07 -0400, Don Slutz wrote: >>>>>> >>>> [snip] >>> I'm not 100% sure of this, but my understanding was that it *would* be a >>> normal IO trap *if* the guest OS gave access to that IO range to the >>> guest (via IOPL, maybe?). But if the userspace program is not >>> explicitly given access by the OS to those ports, it will generate a #GP >>> instead. The idea is to allow the "hypercall" to happen *without >>> cooperation* from the guest OS. >>> >>> Again, that's my understanding, someone please correct me if I'm wrong... >> 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. -Don Slutz > Tim.