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

[Stefan Berger <stefanb@xxxxxxxxxx>]

Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote
on 04/22/2007 02:34:00 PM:

> On 22/4/07 18:35, "Stefan Berger" <stefanb@xxxxxxxxxx>
wrote:

> 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. 
> 
> If you did this with a straightforward domain_create() hook, you 
> could update state at the same time as doing the policy check. Your
> domain_destroy() hook would be called if the creation subsequently
> failed to commit. And if the policy changes at any time after the
> call to your domain_create() hook, you’ve already updated your ACM
> state so you can see the new domain via some internal structure you
> presumably maintains, and hence can re-evaluate the decision under
> the new policy.

The 'internal structure' that represents the label
of the domain is maintained through a pointer connected to the domain structure.
For that reason I would intend to hold the lock on the policy until the
domain has been added to the list of domains.

> 
> In general, keeping checks and state updates together is nice 
> compared with pushing them to pre/post hooks with locks implicitly
> held across the two. That’s just plain gross imo.
> 
> That is, an architecture where you have a ‘pre-doing-stuff’ hook
and
> a ‘pre-destroying-stuff’ hook, where the latter is also called when
> the doing-stuff action turns out to fail, is nicer than pre/post hooks.

 I'll change that in do_domctl().

   Stefan

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