[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [XSM] Potential security vulnerability and inconsistency in evtchn_close

  • To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tan, Lin" <lintan2@xxxxxxxx>
  • Date: Sun, 17 Feb 2008 12:04:22 -0600
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Delivery-date: Sun, 17 Feb 2008 10:04:38 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Achxj4Y3A9B64wJDQdSqfRXw0ecbLA==
  • Thread-topic: [Xen-devel] [XSM] Potential security vulnerability and inconsistency in evtchn_close

Hi All,

I found that evtchn_close() is not checked for authorization by xsm hooks in 
some cases.

There is no xsm permission check before evtchn_close() called in 
do_event_channel_op() as shown below. I imagine, maybe there is no need to 
check if one can close itself, but it is probably still good to add a xsm hook 
inside evtchn_close() in case we decide to expand evtchn_close() to close other 
domains later.

In addition, almost all other functions such as evtchn_send() and 
evtchn_status() put their xsm hooks inside themselves, it would be more 
consistent to add a xsm_evtchn_close() hook in evtchn_close(). What do you 
think? Thanks.

818   long do_event_channel_op(int cmd, XEN_GUEST_HANDLE(void) arg) {
874     case EVTCHNOP_close: {
875         struct evtchn_close close;
876         if ( copy_from_guest(&close, arg, 1) != 0 )
877             return -EFAULT;
878         rc = evtchn_close(&close);
879         break;


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.