WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

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@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