From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH V2 2/3] xen/vm_event: Support for guest-requested events Date: Mon, 6 Jul 2015 17:35:25 +0300 Message-ID: <559A922D.9080600@bitdefender.com> References: <1434359007-9302-1-git-send-email-rcojocaru@bitdefender.com> <1434359007-9302-3-git-send-email-rcojocaru@bitdefender.com> <558D152B0200007800089FD4@mail.emea.novell.com> <5592A659.2040606@bitdefender.com> <559A7422020000780008C9AD@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <559A7422020000780008C9AD@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , dgdegra@tycho.nsa.gov Cc: tim@xen.org, kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, jun.nakajima@intel.com, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, eddie.dong@intel.com, Aravind.Gopalakrishnan@amd.com, suravee.suthikulpanit@amd.com, keir@xen.org, boris.ostrovsky@oracle.com List-Id: xen-devel@lists.xenproject.org On 07/06/2015 01:27 PM, Jan Beulich wrote: >>> No XSM check here or in the handler? Shouldn't the admin controlling >>> guest properties from the host perspective be permitted control here? >>> Cc-ing Daniel for his input ... >> >> Thinking more about this, the goal here is to be able to monitor >> non-privileged guests from a privileged domain. Being able to subscribe >> to these events is subject to XSM checks (so an application in dom0 >> would be able to receive them), but if XSM checks are needed for the >> guest as well, then, at least for the purpose the code is intended for >> now, the default would need to be to allow this to happen. > > Daniel? The examples I've seen of XSM checks in hvm_do_op() require that an argument is provided so that the domain id can be retrieved: 6156 case HVMOP_track_dirty_vram: 6157 { 6158 struct xen_hvm_track_dirty_vram a; 6159 struct domain *d; 6160 6161 if ( copy_from_guest(&a, arg, 1) ) 6162 return -EFAULT; 6163 6164 rc = rcu_lock_remote_domain_by_id(a.domid, &d); 6165 if ( rc != 0 ) 6166 return rc; [...] 6175 rc = xsm_hvm_control(XSM_DM_PRIV, d, op); 6176 if ( rc ) 6177 goto param_fail2; We'll now be sending NULL as the hypercall argument (as previously discussed), but even if we decided to set it to an useful value, I'm not sure how a HVM guest, who presumably is not even aware it's running on top of Xen, can pass a correct ID to the hypervisor for XSM checking here. Also, I'm not quite following how this is different from the other vm_events as far as XSM is concerned. Special permissions are not required for EPT, CR or MSR events, and while the VMCALL-based guest-requested events are bit more involved, in the end it's just as easy (or at least not that more difficult) to run a VMCALL in the guest as it is to write a value to a control register. Unless we get a reply from Daniel soon, I'll send V3 later today so that the rest of the changes discussed last week will have a shot at being reviewed, and I'll of course change the code in V4 should more XSM checks be required. Thanks, Razvan