Re: [Xen-devel] [Xense-devel] [PATCH] [1/4] XSM Framework

[Stefan Berger <stefanb@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx>
> > > [attachment "xsm-121906-xen-unstable.diff" deleted
by Stefan 
> > > Berger/Watson/IBM] _______________________________________________
> > > Xense-devel mailing list
> > > Xense-devel@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/xense-devel
> -- 
> George S. Coker, II <gscoker@xxxxxxxxxxxxxx> 443-479-6944
> 
> 
> _______________________________________________
> 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