[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




xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 04/22/2007 06:07:05 AM:

> 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?


At the beginning of do_domctl() there's the call to acm_pre_domctl, which ends up in its callpath in chwall_pre_domain_create to check whether under the current policy the domain is allowed to be created and it grabs the lock to the policy before doing that.
At the end of the do_domctl() there's the call to acm_post_domctl, in case everything went fine with creating the domain for example. Here it ends up in its callpath in chwall_post_domain_create where it again grabs the lock to the policy and under the assumption that the policy hasn't changed modifies a counter array (running_types).
If the policy is changed in between those calls, i.e. the chinese wall part is changed such that the domain would not be allowed to exist under the new policy, the post-domain-create call would still go through. That's what I want to prevent with a continously-held lock that spans the evaluation at the beginning and the modification of that counter array at the end.

   Stefan


>
>  -- Keir
>
> On 22/4/07 00:02, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:
>
> > This patch restructures the ACM-related code in the do_domctl() function
> > so that the lock to the policy can be fetched in the individual
> > operations, i.e., XEN_DOMCTL_createdomain, and the pair of locking
> > functions acm_rlock_policy()/acm_runlock_policy() don't take the
> > function parameter anymore.
> >
> > Sign-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
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®.