George S. Coker, II
2006-Dec-20 14:08 UTC
[Xen-devel] [Xense-devel] [PATCH] [1/4] XSM Framework
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 operations in 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
Stefan Berger
2006-Dec-20 15:11 UTC
Re: [Xen-devel] [Xense-devel] [PATCH] [1/4] XSM Framework
Hello George,
what''s the to-be-expected side-effect if a hook like this is enforced
(rc
!= 0)?
@@ -2217,6 +2222,10 @@ int do_mmu_update(
*/
case MMU_NORMAL_PT_UPDATE:
+ rc = xsm_mmu_normal_update(current->domain, req.val);
+ if (rc)
+ goto out;
+
gmfn = req.ptr >> PAGE_SHIFT;
mfn = gmfn_to_mfn(d, gmfn);
Stefan
xense-devel-bounces@lists.xensource.com wrote on 12/20/2006 09:08:40 AM:
> 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 operations
> in 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>
> [attachment "xsm-121906-xen-unstable.diff" deleted by Stefan
> Berger/Watson/IBM] _______________________________________________
> Xense-devel mailing list
> Xense-devel@lists.xensource.com
> http://lists.xensource.com/xense-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
George S. Coker, II
2006-Dec-20 16:42 UTC
Re: [Xen-devel] [Xense-devel] [PATCH] [1/4] XSM Framework
It should just be a fault, but I see that EPERM might not be blindly interpreted as EFAULT. On Wed, 2006-12-20 at 10:11 -0500, Stefan Berger wrote:> > Hello George, > > what''s the to-be-expected side-effect if a hook like this is enforced > (rc != 0)? > > @@ -2217,6 +2222,10 @@ int do_mmu_update( > */ > case MMU_NORMAL_PT_UPDATE: > > + rc = xsm_mmu_normal_update(current->domain, req.val); > + if (rc) > + goto out; > + > gmfn = req.ptr >> PAGE_SHIFT; > mfn = gmfn_to_mfn(d, gmfn); > > > Stefan > > xense-devel-bounces@lists.xensource.com wrote on 12/20/2006 09:08:40 > AM: > > > 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 > operations > > in 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> > > [attachment "xsm-121906-xen-unstable.diff" deleted by Stefan > > Berger/Watson/IBM] _______________________________________________ > > Xense-devel mailing list > > Xense-devel@lists.xensource.com > > http://lists.xensource.com/xense-devel-- 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
Stefan Berger
2006-Dec-20 17:39 UTC
Re: [Xen-devel] [Xense-devel] [PATCH] [1/4] XSM Framework
George,
i tried to simulate this hook by deactivating the MMU_NORMAL_PT_UPDATE
like this:
diff -r f80f1cc7f85e xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c Wed Dec 20 09:48:21 2006 +0000
+++ b/xen/arch/x86/mm.c Wed Dec 20 12:30:39 2006 -0500
@@ -2217,6 +2217,9 @@ int do_mmu_update(
*/
case MMU_NORMAL_PT_UPDATE:
+ if (!IS_PRIV(current->domain))
+ goto out;
+
gmfn = req.ptr >> PAGE_SHIFT;
mfn = gmfn_to_mfn(d, gmfn);
Domain-0 starts up fine. When trying to start a guest domain, the effect
on the application level was that an ''xm create <vmconfig
file>'' threw no
error, but the domain never appeared in the domain list - I suppose it
dies.
Otherwise, I saw you have two hooks for pause / unpause of a domain. I
wonder whether this should not rather be only one hook
''pausing'' that
allows one to pause / unpause or disallows both operations, or why would
someone be allow to pause a domain and not unpause it later?
Stefan
xen-devel-bounces@lists.xensource.com wrote on 12/20/2006 11:42:06 AM:
>
> It should just be a fault, but I see that EPERM might not be blindly
> interpreted as EFAULT.
>
> On Wed, 2006-12-20 at 10:11 -0500, Stefan Berger wrote:
> >
> > Hello George,
> >
> > what''s the to-be-expected side-effect if a hook like this is
enforced
> > (rc != 0)?
> >
> > @@ -2217,6 +2222,10 @@ int do_mmu_update(
> > */
> > case MMU_NORMAL_PT_UPDATE:
> >
> > + rc = xsm_mmu_normal_update(current->domain, req.val);
> > + if (rc)
> > + goto out;
> > +
> > gmfn = req.ptr >> PAGE_SHIFT;
> > mfn = gmfn_to_mfn(d, gmfn);
> >
> >
> > Stefan
> >
> > xense-devel-bounces@lists.xensource.com wrote on 12/20/2006 09:08:40
> > AM:
> >
> > > 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
> > operations
> > > in 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>
> > > [attachment "xsm-121906-xen-unstable.diff" deleted by
Stefan
> > > Berger/Watson/IBM]
_______________________________________________
> > > Xense-devel mailing list
> > > Xense-devel@lists.xensource.com
> > > http://lists.xensource.com/xense-devel
> --
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
George S. Coker, II
2006-Dec-20 18:02 UTC
Re: [Xen-devel] [Xense-devel] [PATCH] [1/4] XSM Framework
On Wed, 2006-12-20 at 12:39 -0500, Stefan Berger wrote:> > George, > > i tried to simulate this hook by deactivating the > MMU_NORMAL_PT_UPDATE like this: > > > diff -r f80f1cc7f85e xen/arch/x86/mm.c > --- a/xen/arch/x86/mm.c Wed Dec 20 09:48:21 2006 +0000 > +++ b/xen/arch/x86/mm.c Wed Dec 20 12:30:39 2006 -0500 > @@ -2217,6 +2217,9 @@ int do_mmu_update( > */ > case MMU_NORMAL_PT_UPDATE: > > + if (!IS_PRIV(current->domain)) > + goto out; > + > gmfn = req.ptr >> PAGE_SHIFT; > mfn = gmfn_to_mfn(d, gmfn); > > > Domain-0 starts up fine. When trying to start a guest domain, the > effect on the application level was that an ''xm create <vmconfig > file>'' threw no error, but the domain never appeared in the domain > list - I suppose it dies. >I recall that Domain-0 needs to do some mapping of the other domains pages during construction. This will certainly fail in your example as you have shown. The effect is the domain is never built, but this is not the only hypercall involved in domain construction and so I don''t doubt that there might be orphaned pages (for example) that belonging to a nonexistent domain because of the other hypercalls that were not subject to the policy you have simulated here. IOW, I don''t think that one failed security check should have to clean up after security checks that may have passed under a security policy. However, the control plane may need to be enhanced to better accommodate faults and perform cleanup.> Otherwise, I saw you have two hooks for pause / unpause of a domain. I > wonder whether this should not rather be only one hook ''pausing'' that > allows one to pause / unpause or disallows both operations, or why > would someone be allow to pause a domain and not unpause it later? >Two hooks exist because they have two different code paths. To maintain flexibility and consistency in the XSM, we have two different hooks. A given security module might register the same function twice and use the same permission.> Stefan > > xen-devel-bounces@lists.xensource.com wrote on 12/20/2006 11:42:06 AM: > > > > > It should just be a fault, but I see that EPERM might not be blindly > > interpreted as EFAULT. > > > > On Wed, 2006-12-20 at 10:11 -0500, Stefan Berger wrote: > > > > > > Hello George, > > > > > > what''s the to-be-expected side-effect if a hook like this is > enforced > > > (rc != 0)? > > > > > > @@ -2217,6 +2222,10 @@ int do_mmu_update( > > > */ > > > case MMU_NORMAL_PT_UPDATE: > > > > > > + rc = xsm_mmu_normal_update(current->domain, > req.val); > > > + if (rc) > > > + goto out; > > > + > > > gmfn = req.ptr >> PAGE_SHIFT; > > > mfn = gmfn_to_mfn(d, gmfn); > > > > > > > > > Stefan > > > > > > xense-devel-bounces@lists.xensource.com wrote on 12/20/2006 > 09:08:40 > > > AM: > > > > > > > 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 > > > operations > > > > in 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> > > > > [attachment "xsm-121906-xen-unstable.diff" deleted by Stefan > > > > Berger/Watson/IBM] > _______________________________________________ > > > > Xense-devel mailing list > > > > Xense-devel@lists.xensource.com > > > > http://lists.xensource.com/xense-devel > > -- > > 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-- 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
George S. Coker, II
2006-Dec-20 18:19 UTC
Re: [Xen-devel] [Xense-devel] [PATCH] [1/4] XSM Framework
On Wed, 2006-12-20 at 13:02 -0500, George S. Coker, II wrote:> On Wed, 2006-12-20 at 12:39 -0500, Stefan Berger wrote: > > > > George, > > > > i tried to simulate this hook by deactivating the > > MMU_NORMAL_PT_UPDATE like this: > > > > > > diff -r f80f1cc7f85e xen/arch/x86/mm.c > > --- a/xen/arch/x86/mm.c Wed Dec 20 09:48:21 2006 +0000 > > +++ b/xen/arch/x86/mm.c Wed Dec 20 12:30:39 2006 -0500 > > @@ -2217,6 +2217,9 @@ int do_mmu_update( > > */ > > case MMU_NORMAL_PT_UPDATE: > > > > + if (!IS_PRIV(current->domain)) > > + goto out; > > + > > gmfn = req.ptr >> PAGE_SHIFT; > > mfn = gmfn_to_mfn(d, gmfn); > > > > > > Domain-0 starts up fine. When trying to start a guest domain, the > > effect on the application level was that an ''xm create <vmconfig > > file>'' threw no error, but the domain never appeared in the domain > > list - I suppose it dies. > > > > I recall that Domain-0 needs to do some mapping of the other domains > pages during construction. This will certainly fail in your example as > you have shown. The effect is the domain is never built, but this is > not the only hypercall involved in domain construction and so I don''t > doubt that there might be orphaned pages (for example) that belonging to > a nonexistent domain because of the other hypercalls that were not > subject to the policy you have simulated here. IOW, I don''t think that > one failed security check should have to clean up after security checks > that may have passed under a security policy. However, the control > plane may need to be enhanced to better accommodate faults and perform > cleanup. >It may well be that this exposes that the caller expects certain operations to be atomic but clearly are not. It may suggest that some functions need to be reworked so that they can fault properly.> > Otherwise, I saw you have two hooks for pause / unpause of a domain. I > > wonder whether this should not rather be only one hook ''pausing'' that > > allows one to pause / unpause or disallows both operations, or why > > would someone be allow to pause a domain and not unpause it later? > > > > Two hooks exist because they have two different code paths. To maintain > flexibility and consistency in the XSM, we have two different hooks. A > given security module might register the same function twice and use the > same permission. > > > Stefan > > > > xen-devel-bounces@lists.xensource.com wrote on 12/20/2006 11:42:06 AM: > > > > > > > > It should just be a fault, but I see that EPERM might not be blindly > > > interpreted as EFAULT. > > > > > > On Wed, 2006-12-20 at 10:11 -0500, Stefan Berger wrote: > > > > > > > > Hello George, > > > > > > > > what''s the to-be-expected side-effect if a hook like this is > > enforced > > > > (rc != 0)? > > > > > > > > @@ -2217,6 +2222,10 @@ int do_mmu_update( > > > > */ > > > > case MMU_NORMAL_PT_UPDATE: > > > > > > > > + rc = xsm_mmu_normal_update(current->domain, > > req.val); > > > > + if (rc) > > > > + goto out; > > > > + > > > > gmfn = req.ptr >> PAGE_SHIFT; > > > > mfn = gmfn_to_mfn(d, gmfn); > > > > > > > > > > > > Stefan > > > > > > > > xense-devel-bounces@lists.xensource.com wrote on 12/20/2006 > > 09:08:40 > > > > AM: > > > > > > > > > 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 > > > > operations > > > > > in 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> > > > > > [attachment "xsm-121906-xen-unstable.diff" deleted by Stefan > > > > > Berger/Watson/IBM] > > _______________________________________________ > > > > > Xense-devel mailing list > > > > > Xense-devel@lists.xensource.com > > > > > http://lists.xensource.com/xense-devel > > > -- > > > 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-- 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
Stefan Berger
2006-Dec-20 18:32 UTC
Re: [Xen-devel] [Xense-devel] [PATCH] [1/4] XSM Framework
xen-devel-bounces@lists.xensource.com wrote on 12/20/2006 01:02:26 PM:> On Wed, 2006-12-20 at 12:39 -0500, Stefan Berger wrote: > > > > George, > > > > i tried to simulate this hook by deactivating the > > MMU_NORMAL_PT_UPDATE like this: > > > > > > diff -r f80f1cc7f85e xen/arch/x86/mm.c > > --- a/xen/arch/x86/mm.c Wed Dec 20 09:48:21 2006 +0000 > > +++ b/xen/arch/x86/mm.c Wed Dec 20 12:30:39 2006 -0500 > > @@ -2217,6 +2217,9 @@ int do_mmu_update( > > */ > > case MMU_NORMAL_PT_UPDATE: > > > > + if (!IS_PRIV(current->domain)) > > + goto out; > > + > > gmfn = req.ptr >> PAGE_SHIFT; > > mfn = gmfn_to_mfn(d, gmfn); > > > > > > Domain-0 starts up fine. When trying to start a guest domain, the > > effect on the application level was that an ''xm create <vmconfig > > file>'' threw no error, but the domain never appeared in the domain > > list - I suppose it dies. > > > > I recall that Domain-0 needs to do some mapping of the other domains > pages during construction. This will certainly fail in your example as > you have shown. The effect is the domain is never built, but this isIn the above patch ''goto out'' is ONLY called if the domain calling this function is NOT a privileged domain. Domain-0 is privileged and will therefore not ''goto out''. So I think it''s more the guest domain that''s trying to call this function and fails.> not the only hypercall involved in domain construction and so I don''t > doubt that there might be orphaned pages (for example) that belonging to > a nonexistent domain because of the other hypercalls that were not > subject to the policy you have simulated here. IOW, I don''t think that > one failed security check should have to clean up after security checks > that may have passed under a security policy. However, the control > plane may need to be enhanced to better accommodate faults and perform > cleanup. > > > Otherwise, I saw you have two hooks for pause / unpause of a domain. I > > wonder whether this should not rather be only one hook ''pausing'' that > > allows one to pause / unpause or disallows both operations, or why > > would someone be allow to pause a domain and not unpause it later? > > > > Two hooks exist because they have two different code paths. To maintain > flexibility and consistency in the XSM, we have two different hooks. A > given security module might register the same function twice and use the > same permission.So there are policies that might allow you to pause but not unpause? Stefan> > > Stefan > > > > xen-devel-bounces@lists.xensource.com wrote on 12/20/2006 11:42:06 AM: > > > > > > > > It should just be a fault, but I see that EPERM might not be blindly > > > interpreted as EFAULT. > > > > > > On Wed, 2006-12-20 at 10:11 -0500, Stefan Berger wrote: > > > > > > > > Hello George, > > > > > > > > what''s the to-be-expected side-effect if a hook like this is > > enforced > > > > (rc != 0)? > > > > > > > > @@ -2217,6 +2222,10 @@ int do_mmu_update( > > > > */ > > > > case MMU_NORMAL_PT_UPDATE: > > > > > > > > + rc = xsm_mmu_normal_update(current->domain, > > req.val); > > > > + if (rc) > > > > + goto out; > > > > + > > > > gmfn = req.ptr >> PAGE_SHIFT; > > > > mfn = gmfn_to_mfn(d, gmfn); > > > > > > > > > > > > Stefan > > > > > > > > xense-devel-bounces@lists.xensource.com wrote on 12/20/2006 > > 09:08:40 > > > > AM: > > > > > > > > > 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 > > > > operations > > > > > in 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> > > > > > [attachment "xsm-121906-xen-unstable.diff" deleted by Stefan > > > > > Berger/Watson/IBM] > > _______________________________________________ > > > > > Xense-devel mailing list > > > > > Xense-devel@lists.xensource.com > > > > > http://lists.xensource.com/xense-devel > > > -- > > > 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 > -- > 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George S. Coker, II
2006-Dec-20 18:40 UTC
Re: [Xen-devel] [Xense-devel] [PATCH] [1/4] XSM Framework
> > So there are policies that might allow you to pause but not unpause? >I think I can conceive of a policy where a domain has permission to pause a group of domains, but may not have the permission to unpause them, i.e. to ensure that a given workflow process is one-way.> Stefan >-- 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
Keir Fraser
2006-Dec-21 10:53 UTC
Re: [Xen-devel] [Xense-devel] [PATCH] [1/4] XSM Framework
On 20/12/06 14:08, "George S. Coker, II" <gscoker@alpha.ncsc.mil> wrote:> 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.ACM code is currently present in xen, xend and in the xm command-line tool. Do the XSM patches remove all this ACM-specific code, since (I believe) XSM logically subsumes ACM? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Peter A. Loscocco
2006-Dec-21 20:39 UTC
Re: [Xen-devel] [Xense-devel] [PATCH] [1/4] XSM Framework
On Thu, 2006-12-21 at 10:53 +0000, Keir Fraser wrote:> ACM code is currently present in xen, xend and in the xm command-line tool. > Do the XSM patches remove all this ACM-specific code, since (I believe) XSM > logically subsumes ACM?It is the intention that XSM would subsume ACM with the functionality that ACM provides being in an ACM-specific XSM module. In Xen itself, it is like that now. The ACM code is in the ACM module. There still needs to be some thought given to what the correct user- space interfaces should be. The current implementation uses the existing ACM interfaces. There are different implementations of the functions behind those interfaces for each XSM module. Which set of functions is used depends on which XSM module has been installed. -- Peter Loscocco National Security Agency _______________________________________________ Xense-devel mailing list Xense-devel@lists.xensource.com http://lists.xensource.com/xense-devel