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:
>
> > purpose of the security field is not only to facilitate information
> > flows to resources, virtual or physical, in the hypervisor, but also to
> > facilitate guests in the ability to identify channels based on these
> > security properties and support information flows mediated by these
> > guests. This is really an important property for creating secure
> > channels between domains as well as other resources (virtual or
> > physical) resources.
>
> E.g., the information flow from timer events to a guest? I can't envisage
> what kinds of policies you might have in mind. I'm probably missing some
> bigger picture.
>
Perhaps, but I think that for now, it is hard to prove value for the
hooks covering virq, ipi, and pirq, so they should be ommitted.
> > 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.
> -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home
xen.org, 