Re: [Xen-devel] [PATCH V2 2/3] xen/vm_event: Support for guest-requested events

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

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

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