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

[Stefan Berger <stefanb@xxxxxxxxxx>]

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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel