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

[Stefan Berger <stefanb@xxxxxxxxxx>]

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