[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
> I think that relying on domctl wrapper functions to do necessary label
> bookkeeping on domain create/destroy is making things more complicated
> they need to be. Wrapper functions are obviously the right answer
> ACM functions (since they are allow/deny checks, external to the core
> 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(),
> latter from the error path of domain_create() and from domain_destroy().
> You can then have appropriate critical regions *within* those functions
> across them) that you synchronise against when relabelling the world.
> 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.
> -- Keir
> On 22/4/07 00:02, "Stefan Berger" <stefanb@xxxxxxxxxx>
> > This patch restructures the ACM-related code in the do_domctl()
> > 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
> > 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 mailing list