[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
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
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
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.
Xen-devel mailing list