Xen devel - Mar 2007 - [Xense-devel][PATCH][XSM][1/4] Xen Security Modules Patch

This patch provides the basic XSM framework for x86_32/x86/64.  It
includes a dummy module that implements call/return for each security
function. 

The hooks implemented by this patch provide a framework for security
modules to interpose and complement the existing privileged hypercall 
operationsin xen as well as interpose on the discretionary operations 
between domains.

I have done very casual performance testing of the XSM in comparison to
native xen.  The XSM (with or without the dummy module) has negligible
impact as measured by lmbench and kbench from either dom0 or domU.  The
tests were conducted on xen running idle dom0''s and idle
domU''s.  The
micro-benchmarks can/do especially vary when a security module (other
than the dummy module) is in place.  This is to be expected.  The macro-
benchmarks for a specific security module tend to average out the micro-
benchmark variations but may not be representative of a real platform
workload.

The framework is configured as default-enable in this patch set.
Configuration of XSM is made in Config.mk.  The only configuration
option is XSM_ENABLE = y/n.  XSM_ENABLE must be y to compile an XSM
module.  

XSM provides a generalized hook infrastructure allowing third-party
security modules to interpose on the Xen code path.  A default or dummy
module provides basic call/return functionality for hooks not
implemented by a given module.  During module initialization, a module
registers its security hooks and the equivalent dummy hooks are
unregistered.  If a module does not implement a hook, the equivalent
dummy hook remains in place.  Modules also may define and register at
boot time a module specific hypercall through the XSM hook
infrastructure.

Modules may also define at Xen compile time a magic number XSM_MAGIC to
indicate that a policy should be discovered from the images loaded at
boot.  The policy file should then be listed in grub as one of the
multi-boot modules after the dom0 kernel.

Signed-off-by: George Coker <gscoker@alpha.ncsc.mil>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2007-03-08 at 10:28 -0500, George S. Coker, II
wrote:
> +    /*
> +     * Try all modules and see whichever could be the binary policy.
> +     * Adjust the initrdidx if module[1] is the binary policy.
> +     */
> +    for (i = mbi->mods_count-1; i >= 1; i--) {
> +#if defined(__i386__)
> +        _policy_start = (u32 *)(initial_images_start +
(mod[i].mod_start-mod[0].mod_start));
> +#elif defined(__x86_64__)
> +        _policy_start = __va(initial_images_start +
(mod[i].mod_start-mod[0].mod_start));
> +#else
> +#error Architecture unsupported by XSM
> +#endif
   This is unacceptable, please make it fail gracefully on non-x86.
Thanks,

	Alex
 
-- 
Alex Williamson                             HP Open Source & Linux Org.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2007-03-08 at 08:59 -0700, Alex Williamson
wrote:
> On Thu, 2007-03-08 at 10:28 -0500, George S. Coker, II wrote:
> > +    /*
> > +     * Try all modules and see whichever could be the binary policy.
> > +     * Adjust the initrdidx if module[1] is the binary policy.
> > +     */
> > +    for (i = mbi->mods_count-1; i >= 1; i--) {
> > +#if defined(__i386__)
> > +        _policy_start = (u32 *)(initial_images_start +
(mod[i].mod_start-mod[0].mod_start));
> > +#elif defined(__x86_64__)
> > +        _policy_start = __va(initial_images_start +
(mod[i].mod_start-mod[0].mod_start));
> > +#else
> > +#error Architecture unsupported by XSM
> > +#endif
> 
>    This is unacceptable, please make it fail gracefully on non-x86.
Indeed, it looks like this logic is outdated.  This was based on some
older code from ACM.  The attached patch addresses this issue.

> Thanks,
> 
> 	Alex
>  
-- 
George S. Coker, II <gscoker@alpha.ncsc.mil> 443-479-6944


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 8/3/07 15:28, "George S. Coker, II" <gscoker@alpha.ncsc.mil>
wrote:
> The hooks implemented by this patch provide a framework for security
> modules to interpose and complement the existing privileged hypercall
> operationsin xen as well as interpose on the discretionary operations
> between domains.
I guess the primary question here is whether the set of hooks is reasonable.
The approach here seems to be comprehensive, to say the least.

For example, do we envisage policies where it is not only desirable to
interpose at event-channel binding time (particularly for interdomain
channels) but also on every send? Do you need to interpose on all types of
bindings? Interposing on interdomain bindings is obviously required, but
virq/pirq/ipi seem pretty dubious to me: virq/ipi bindings have only
local-domain scope, and protection of physical resources (like pirqs) is
already done via io capabilities.

Picking another example, is it useful to distinguish between the different
ways that a domain can act on the visible state of an HVM guest. For
example, you have hooks for setting pci link routes, and changing isa and
pci intx interrupt levels (as separate hooks!): it seems to me that some
more abstract capability could cover all these cases without loss of useful
generality.

As for the rest of the patches, I suspect they''ll be largely okay. We
should
refactor all the security code in Xen to sit under xen/security or xen/xsm.
In particular, flask/ and acm/ would be relocated under here. When you add
hook code to existing files, please format the code to that file''s
conventions (which are typically not k&r or linux style!). The flask_op()
hypercall interface is rather opaque -- shouldn''t you have a public
header
file to define what that interface is? Having the command enumeration
directly above the hypercall implementation (and so private to Xen) seems
odd. And I''m not sure about the Plan9-style sscanf-of-strings interface
either. It should at least be documented. :-)

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2007-03-08 at 11:16 -0500, George S. Coker, II
wrote:
> On Thu, 2007-03-08 at 08:59 -0700, Alex Williamson wrote:
> > On Thu, 2007-03-08 at 10:28 -0500, George S. Coker, II wrote:
> > > +    /*
> > > +     * Try all modules and see whichever could be the binary
policy.
> > > +     * Adjust the initrdidx if module[1] is the binary policy.
> > > +     */
> > > +    for (i = mbi->mods_count-1; i >= 1; i--) {
> > > +#if defined(__i386__)
> > > +        _policy_start = (u32 *)(initial_images_start +
(mod[i].mod_start-mod[0].mod_start));
> > > +#elif defined(__x86_64__)
> > > +        _policy_start = __va(initial_images_start +
(mod[i].mod_start-mod[0].mod_start));
> > > +#else
> > > +#error Architecture unsupported by XSM
> > > +#endif
> > 
> >    This is unacceptable, please make it fail gracefully on non-x86.
> 
> Indeed, it looks like this logic is outdated.  This was based on some
> older code from ACM.  The attached patch addresses this issue.
   Thanks!

	Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2007-03-08 at 16:21 +0000, Keir Fraser wrote:
> On 8/3/07 15:28, "George S. Coker, II"
<gscoker@alpha.ncsc.mil> wrote:
> 
> > The hooks implemented by this patch provide a framework for security
> > modules to interpose and complement the existing privileged hypercall
> > operationsin xen as well as interpose on the discretionary operations
> > between domains.
> 
> I guess the primary question here is whether the set of hooks is
reasonable.
> The approach here seems to be comprehensive, to say the least.
> 
> For example, do we envisage policies where it is not only desirable to
> interpose at event-channel binding time (particularly for interdomain
> channels) but also on every send? 
The check on send, enables for the flask module the creation of a one-
way event channel.  Flask can check whether A can send to B, but this
does not imply that B can send to A.  The primary value for this check
is in the construction of one-way information flows.
> Do you need to interpose on all types of
> bindings? Interposing on interdomain bindings is obviously required, but
> virq/pirq/ipi seem pretty dubious to me: virq/ipi bindings have only
> local-domain scope, and protection of physical resources (like pirqs) is
> already done via io capabilities.
> 
The pirq bindings are meant to protect the hypervisor against abuse by
the control-plane, thereby ensuring that the control-plane cannot setup
resource bindings that are prohibited by the policy.  The control-plane
in this argument is decomposed or deprivileged by the running policy
such that it is unable to cause a policy reload and circumvent these
checks.

While the virq/ipi have local-domain scope, it is in the interest of
comprehensiveness that this hooks exists.  For a domain running a
general purpose OS, this hook has little value since anything checked
here will always likely need to be granted.  However, light-weight
domains for which the enforced policy could be justifiably more
restrictive, would benefit from this hook.  I admit the value is
unproven for Xen today. ;)
> Picking another example, is it useful to distinguish between the different
> ways that a domain can act on the visible state of an HVM guest. For
> example, you have hooks for setting pci link routes, and changing isa and
> pci intx interrupt levels (as separate hooks!): it seems to me that some
> more abstract capability could cover all these cases without loss of useful
> generality.
> 
Separate hooks does not necessarily mean separate permissions - the
breakdown of permissions is module dependent.  Separate hooks allows for
a narrower per-hook interface (ensuring that the hooks are unlikely to
be abused for non-security purposes) and makes it unlikely that a given
hook will be separated from or lose context with the critical code path.
> As for the rest of the patches, I suspect they''ll be largely okay.
We should
> refactor all the security code in Xen to sit under xen/security or xen/xsm.
> In particular, flask/ and acm/ would be relocated under here. When you add
> hook code to existing files, please format the code to that file''s
> conventions (which are typically not k&r or linux style!). 
Yes.
> The flask_op()
> hypercall interface is rather opaque -- shouldn''t you have a
public header
> file to define what that interface is? Having the command enumeration
> directly above the hypercall implementation (and so private to Xen) seems
> odd. And I''m not sure about the Plan9-style sscanf-of-strings
interface
> either. It should at least be documented. :-)
> 
Fair enough.  Up to this point, I''ve been trying to reduce the amount
of
code deposited and made public across the Xen tree.  It was not my
intention to hide the flask_op hypercall command structure.
Documentation will be forth coming after we straighten out any other
issues wrt XSM.
>  -- Keir
-- 
George S. Coker, II <gscoker@alpha.ncsc.mil> 443-479-6944


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 8/3/07 18:08, "George S. Coker, II" <gscoker@alpha.ncsc.mil>
wrote:
> The check on send, enables for the flask module the creation of a one-
> way event channel.  Flask can check whether A can send to B, but this
> does not imply that B can send to A.  The primary value for this check
> is in the construction of one-way information flows.
Fair enough.
> The pirq bindings are meant to protect the hypervisor against abuse by
> the control-plane, thereby ensuring that the control-plane cannot setup
> resource bindings that are prohibited by the policy.  The control-plane
> in this argument is decomposed or deprivileged by the running policy
> such that it is unable to cause a policy reload and circumvent these
> checks.
You can restrict this via the iocaps mechanism, and I''ll bet you
already
include a hook that could prevent the domain from modifying its own iocaps
in a disallowed way. :-)
> While the virq/ipi have local-domain scope, it is in the interest of
> comprehensiveness that this hooks exists.  For a domain running a
> general purpose OS, this hook has little value since anything checked
> here will always likely need to be granted.  However, light-weight
> domains for which the enforced policy could be justifiably more
> restrictive, would benefit from this hook.
I don''t think this is true. Same applies to evtchn_close(): another
entirely
local VM operation. It seems outside the scope of XSM policy to be hooking
those. If you were to go this route then wouldn''t you essentially be
arguing
for interception of *every* hypercall subcommand?
> Separate hooks does not necessarily mean separate permissions - the
> breakdown of permissions is module dependent.  Separate hooks allows for
> a narrower per-hook interface (ensuring that the hooks are unlikely to
> be abused for non-security purposes) and makes it unlikely that a given
> hook will be separated from or lose context with the critical code path.
If new critical code paths are added then XSM could end up with a set of
critical paths that it doesn''t hook at all. That would be less of a
problem
if the hooks aren''t pushed way down into hypercall subcommands. I guess
you
can argue this one either way. With this scheme you don''t end up having
to
demux the hypercall subcommands in every XSM module implementation.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> When you add
> > hook code to existing files, please format the code to that
file''s
> > conventions (which are typically not k&r or linux style!). 
> 
Attached is an xsm patch updated for coding style.....

-- 
George S. Coker, II <gscoker@alpha.ncsc.mil> 443-479-6944


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > The pirq bindings are meant to protect the hypervisor against abuse by
> > the control-plane, thereby ensuring that the control-plane cannot
setup
> > resource bindings that are prohibited by the policy.  The
control-plane
> > in this argument is decomposed or deprivileged by the running policy
> > such that it is unable to cause a policy reload and circumvent these
> > checks.
> 
> You can restrict this via the iocaps mechanism, and I''ll bet you
already
> include a hook that could prevent the domain from modifying its own iocaps
> in a disallowed way. :-)
> 
Right, while we do check the iocaps setup, there is more value here than
a simple check on bind.  XSM has also introduced a security field for
event channels.  The value of this security field can only practically
be computed at bind time, so whether a security module wants to do a
permission check on binding for pirq/virq/ipi is not as relevant as
whether the module needs to assign a security field to the channel.  The
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.
> > While the virq/ipi have local-domain scope, it is in the interest of
> > comprehensiveness that this hooks exists.  For a domain running a
> > general purpose OS, this hook has little value since anything checked
> > here will always likely need to be granted.  However, light-weight
> > domains for which the enforced policy could be justifiably more
> > restrictive, would benefit from this hook.
> 
> I don''t think this is true. Same applies to evtchn_close():
another entirely
> local VM operation. It seems outside the scope of XSM policy to be hooking
> those. If you were to go this route then wouldn''t you essentially
be arguing
> for interception of *every* hypercall subcommand?
> 
I certainly do not want to go down the path of intercepting *every*
hypercall subcommand.  Let me give a bit more detail about what kinds of
capabilities that I am suggesting.  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.
> > Separate hooks does not necessarily mean separate permissions - the
> > breakdown of permissions is module dependent.  Separate hooks allows
for
> > a narrower per-hook interface (ensuring that the hooks are unlikely to
> > be abused for non-security purposes) and makes it unlikely that a
given
> > hook will be separated from or lose context with the critical code
path.
> 
> If new critical code paths are added then XSM could end up with a set of
> critical paths that it doesn''t hook at all. That would be less of
a problem
> if the hooks aren''t pushed way down into hypercall subcommands. I
guess you
> can argue this one either way. With this scheme you don''t end up
having to
> demux the hypercall subcommands in every XSM module implementation.
It does go either way, but hopefully, as XSM becomes part of Xen, new
hooks or the need for new hooks won''t be as opaque as it is in the
roll-
up implementation.  At least in the current XSM, it is clear as to what
is/not checked.  Another issue is demuxing in the hook forces a wide
hook interface - not to mention needless hook processing on every entry
to the hypercall.  Demuxing in the hook also makes the hook and the rest
of Xen ripe for abuse ala typical ioctl style issues.

George
> 
>  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 8/3/07 19:58, "George S. Coker, II" <gscoker@alpha.ncsc.mil>
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.
> 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?

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 2007-03-09 at 09:43 +0000, Keir Fraser wrote:
> On 8/3/07 19:58, "George S. Coker, II"
<gscoker@alpha.ncsc.mil> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com 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@alpha.ncsc.mil> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 2007-03-09 at 12:51 -0500, Stefan Berger wrote:
> 
> xen-devel-bounces@lists.xensource.com 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@alpha.ncsc.mil>
> 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@lists.xensource.com
> > http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com wrote on 03/09/2007 03:04:56 PM:
> On Fri, 2007-03-09 at 12:51 -0500, Stefan Berger wrote:
> > 
> > xen-devel-bounces@lists.xensource.com 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@alpha.ncsc.mil>
> > 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.
Why is there mediation in evtchn_reset [.evtchn_reset]? It looks like the 
code tries to only close an event channel if necessary. I suppose that 
once you have been allowed to open an event channel you should be able to 
reset (close) it. 

   Stefan
> 
> >    Stefan 
> > 
> > 
> > > >  -- Keir
> > > 
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> Why is there mediation in evtchn_reset [.evtchn_reset]? It looks like
> the code tries to only close an event channel if necessary. I suppose
> that once you have been allowed to open an event channel you should be
> able to reset (close) it.  
> 
To deprivilege the hypercall, because it can be called by an
unprivileged domain on itself and by a privileged domain on another
domain.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

It¹s a bit different from close because it can act cross-domain. It doesn¹t
necessarily act on the caller.

 K.

On 9/3/07 22:01, "Stefan Berger" <stefanb@us.ibm.com>
wrote:
> 
> 
> Why is there mediation in evtchn_reset [.evtchn_reset]? It looks like the
code
> tries to only close an event channel if necessary. I suppose that once you
> have been allowed to open an event channel you should be able to reset
(close)
> it. 
> 
>    Stefan 
> 
>> > 
>>> > >    Stefan 
>>> > > 
>>> > > 
>>>>> > > > >  -- Keir
>>>> > > > 
>>>> > > > 
>>>> > > > _______________________________________________
>>>> > > > Xen-devel mailing list
>>>> > > > Xen-devel@lists.xensource.com
>>>> > > > http://lists.xensource.com/xen-devel
>> > 
>> > 
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xensource.com
>> > http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Updates in this patch set include:
    - security module code managed under xsm/
    - removal of local event channel hooks
    - cleanup of xsm_policy.c
    - style cleanups of hook code

Signed-off-by: George Coker <gscoker@alpha.ncsc.mil>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel