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