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
 
   
 

xen-devel

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