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

Re: [Xen-devel] xsm_op() polymorphism

On Mon, Dec 10, 2007 at 07:05:03PM -0500, George S. Coker, II wrote:

> > If I'm reading the code right, then the xsm_op() hypercall is "untyped"
> > in the sense that you have to know why XSM is loaded before you can
> > interpret any of the contents (that is, the first argument points
> > directly to a flask op or acm op structure). This seems less than ideal
> > - can't we work out a way to make the struct self-identifying?
> >
> 
> It depends on what you are concerned about.  There are the magic
> numbers that are used right now to identify policy modules on boot but
> could become embedded as the first word of the xsm op structure.  This
> would help the hypervisor be consistent with user-space - if that's
> what you are concerned about.  It was not the intent to make the
> hypervisor runtime agile wrt a given security module except to not
> prevent a security module from runtime disablement - for obvious
> reasons more flexibility here is fraught with consistency problems.

My immediate concern is that we have to do some snooping into hypercalls
on Solaris (for reasons not of much interest) - and we can't actually
know what structure is being passed in without magically guessing what
type of structure it is. But more generally it's not a good interface to
not only have to assume something incoming is a particular struct, but
have no way of checking that (since the 'op' number-space is shared too)

If there's already a magic-number allocation for the XSMs then great, it
certainly seems like we should use that.

regards
john

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

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