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

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

On Wed, 2006-12-20 at 13:02 -0500, George S. Coker, II wrote:
> On Wed, 2006-12-20 at 12:39 -0500, Stefan Berger wrote:
> > 
> > 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. 
> > 
> 
> I recall that Domain-0 needs to do some mapping of the other domains
> pages during construction.  This will certainly fail in your example as
> you have shown.  The effect is the domain is never built, but this is
> not the only hypercall involved in domain construction and so I don't
> doubt that there might be orphaned pages (for example) that belonging to
> a nonexistent domain because of the other hypercalls that were not
> subject to the policy you have simulated here.  IOW, I don't think that
> one failed security check should have to clean up after security checks
> that may have passed under a security policy.  However, the control
> plane may need to be enhanced to better accommodate faults and perform
> cleanup.
> 

It may well be that this exposes that the caller expects certain
operations to be atomic but clearly are not.  It may suggest that some
functions need to be reworked so that they can fault properly.

> > 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? 
> > 
> 
> Two hooks exist because they have two different code paths.  To maintain
> flexibility and consistency in the XSM, we have two different hooks.  A
> given security module might register the same function twice and use the
> same permission.
> 
> >   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
-- 
George S. Coker, II <gscoker@xxxxxxxxxxxxxx> 443-479-6944


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel