WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] About XSM/flask

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] About XSM/flask
From: Jean-Edouard LEJOSNE <jean-edouard.lejosne@xxxxxxxxxx>
Date: Wed, 22 Sep 2010 16:46:16 +0100
Delivery-date: Wed, 22 Sep 2010 08:47:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
 Hi!

I've got some trouble with XSM/flask recently.
Basically, it blocks stuffs when not enforced, which is not (?) supposed to 
happen.

The problem is actually pretty simple when looking at the code.
As an example, here is a function from xen/xsm/flask/hooks.c :

static int flask_hvm_param(struct domain *d, unsigned long op)
{
     u32 perm;

     switch ( op )
     {
         case HVMOP_set_param:
             perm = HVM__SETPARAM;
         break;
         case HVMOP_get_param:
             perm = HVM__GETPARAM;
         break;
         default:
             return -EPERM;
     }

     return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
}

As it is pretty obvious, if "op" is not "HVMOP_set_param" or
"HVMOP_get_param", XSM will deny the action, even if we are in permissive mode.
It is currently a problem for us because, for this particular function
at least, we use other values of "op" (for dirty bit tracking).

I think in that case, flask should just print a warning and return 0
when in permissive mode.
The only other solution I see is to make sure every possible values are
treated by flask, and that it's maintained that way, which is probably a
pain.

So my question is : is there something that should be done about that? Is the 
current behaviour mandatory for some reason I didn't think about?

Thanks,

--
Jean-Edouard LEJOSNE
XenClient Lead Software Developpment Engineer
Citrix Systems
Cambridge, UK


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>