All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Jan Beulich <JBeulich@suse.com>, 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
Subject: Re: [PATCH V2 2/3] xen/vm_event: Support for guest-requested events
Date: Mon, 6 Jul 2015 17:35:25 +0300	[thread overview]
Message-ID: <559A922D.9080600@bitdefender.com> (raw)
In-Reply-To: <559A7422020000780008C9AD@mail.emea.novell.com>

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

  reply	other threads:[~2015-07-06 14:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-15  9:03 Vm_event memory introspection helpers Razvan Cojocaru
2015-06-15  9:03 ` [PATCH V2 1/3] xen/vm_access: Support for memory-content hiding Razvan Cojocaru
2015-06-25 15:57   ` Jan Beulich
2015-06-26  8:22     ` Razvan Cojocaru
2015-06-26  8:44       ` Jan Beulich
2015-06-26  9:49         ` Razvan Cojocaru
2015-06-26  9:59           ` Jan Beulich
2015-06-15  9:03 ` [PATCH V2 2/3] xen/vm_event: Support for guest-requested events Razvan Cojocaru
2015-06-24 14:56   ` Razvan Cojocaru
2015-06-24 15:03     ` Jan Beulich
2015-06-25  7:55       ` Razvan Cojocaru
2015-06-25  8:37         ` Jan Beulich
2015-06-25  9:09           ` Razvan Cojocaru
2015-06-26  7:02   ` Jan Beulich
2015-06-26  7:17     ` Razvan Cojocaru
2015-06-26  8:45       ` Jan Beulich
2015-06-30 14:48       ` Lengyel, Tamas
2015-06-30 15:22         ` Razvan Cojocaru
2015-07-01  8:24         ` Razvan Cojocaru
2015-07-06 10:26         ` Jan Beulich
2015-07-06 13:46           ` Lengyel, Tamas
2015-06-30 14:23     ` Razvan Cojocaru
2015-07-06 10:27       ` Jan Beulich
2015-07-06 14:35         ` Razvan Cojocaru [this message]
2015-06-15  9:03 ` [PATCH V2 3/3] xen/vm_event: Deny register writes if refused by vm_event reply Razvan Cojocaru
2015-06-26  8:28   ` Jan Beulich
2015-06-26  9:17     ` Razvan Cojocaru
2015-06-26  9:39       ` Jan Beulich
2015-06-26 10:33         ` Razvan Cojocaru
2015-07-01 15:21     ` Razvan Cojocaru

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=559A922D.9080600@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=Aravind.Gopalakrishnan@amd.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=eddie.dong@intel.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.