WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [XEN] [ACM] [2/2] Restructuring ACM-related code in do_domctl
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Sun, 22 Apr 2007 13:35:00 -0400
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 22 Apr 2007 10:33:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C250F259.61BE%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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