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

[Stefan Berger <stefanb@xxxxxxxxxx>]

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 12/20/2006
01:02:26 PM:

> 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

In the above patch 'goto out' is ONLY called if the
domain calling this function is NOT a privileged domain. Domain-0 is privileged
and will therefore not 'goto out'. So I think it's more the guest domain
that's trying to call this function and fails.


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

So there are policies that might allow you to pause
but not unpause?

   Stefan

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