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

["George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>]

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