Re: [Xen-devel][Xense-devel][PATCH][XSM][1/4] Xen Security Modules Patch

["George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>]

On Fri, 2007-03-09 at 12:51 -0500, Stefan Berger wrote:
> 
> 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? 
> 
In light of the other comments, you are correct.

>    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