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][Xense-devel][PATCH][XSM][1/4] Xen Security Modules Patch

To: "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel][Xense-devel][PATCH][XSM][1/4] Xen Security Modules Patch
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Fri, 9 Mar 2007 12:51:32 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>, xense-devel@xxxxxxxxxxxxxxxxxxx, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 09 Mar 2007 09:51:42 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1173459311.24363.18.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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 03/09/2007 11:55:11 AM:

> On Fri, 2007-03-09 at 09:43 +0000, Keir Fraser wrote:
> > On 8/3/07 19:58, "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx> wrote:
> >
>
> > > To achieve a very light-weight
> > > domain, one would like to remove as much functionality from that domain
> > > as possible, to include the interrupt handler.  Instead, there would
> > > exist a light-weight domain interrupt handler domain that is responsible
> > > for this functionality.  These interrupts would manifest as interdomain
> > > channels; however, the ipi mechanism remains unless a hook exists to
> > > block this code path.  Likewise, the light-weight domains wouldn't be
> > > able to close their channels arbitrarily, and require a check on close
> > > as well.
> >
> > I think this sounds like a microkernel-style 'interrupt server'? Why would
> > you want that? And if you did have it, why would you care about the clients
> > of this server closing their ends of interdomain event channels?
> >
> Fair enough.  I'll remove the close check, although we will still need a
> hook in the close code path for cleanup.
>


There's also a mediation in evtchn_init() [.evtchn_init]. evtchn_init() is called from one since place only and that is domain_create(), which in turn is behind the xsm_createdomain() mediation call [.createdomain]. I suppose it would be enough to guard the creation of a domain by the xsm_createdomain() hook only, no?

   Stefan


> >  -- Keir
>
>
> _______________________________________________
> 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
<Prev in Thread] Current Thread [Next in Thread>