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

Re: [Xen-devel] [PATCH] [XEN] [ACM] [2/2] Restructuring ACM-related code in do_domctl



On Sun, 2007-04-22 at 11:07 +0100, Keir Fraser wrote:
> I think that relying on domctl wrapper functions to do necessary label
> bookkeeping on domain create/destroy is making things more complicated than
> they need to be. Wrapper functions are obviously the right answer for most
> ACM functions (since they are allow/deny checks, external to the core logic
> of the operation being checked), but in the case of domain create/destroy
> ACM is more part of the process.
> 
> So, how about having functions: domain_acm_create() and
> domain_acm_destroy()? The former would be called from domain_create(), the
> latter from the error path of domain_create() and from domain_destroy().
> 
> You can then have appropriate critical regions *within* those functions (not
> across them) that you synchronise against when relabelling the world. And
> you shouldn't then need to modify do_domctl() at all?
> 

I'll chime in here, although my response applies to later parts of the
thread.

XSM provides hooks in domain_create and domain_destroy so that modules
can do these kinds of operations.  There are some side issues that need
to be considered in the creation of these hooks, such as when
domain_create is first called and when any security module is
initialized.  In my experience it has been straightforward to factor the
existing sHype(ACM) module to take advantage of these additional
hooks.  

A nice side effect (for sHype(ACM)) of the domain_destroy hook is we can
clean up the destroy domain operation in do_domctl by removing the local
ssid variable as well ensure that the security object is destroyed/freed
last.

I'll be posting some updated and cleaned up XSM patches later
today/tomorrow.  I realize many may be distracted with the 3.0.5 release
candidate, but this should help me get XSM into good shape for when
3.0.6 opens up for patches.

George


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


 


Rackspace

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