[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: [Xen-staging] [xen-unstable] Xen Security Modules: XSM



On Tue, 2007-09-04 at 11:28 -0600, Alex Williamson wrote:
> On Tue, 2007-09-04 at 13:22 -0400, George S. Coker, II wrote:
> > On Tue, 2007-09-04 at 08:07 -0600, Alex Williamson wrote:
> > > On Fri, 2007-08-31 at 11:22 +0100, Xen staging patchbot-unstable wrote:
> > > > diff -r 0f196e11a143 -r 96f64f4c42f0 xen/include/xsm/xsm.h
> > > > --- /dev/null   Thu Jan 01 00:00:00 1970 +0000
> > > > +++ b/xen/include/xsm/xsm.h     Fri Aug 31 11:21:35 2007 +0100
> > > ...
> > > > +    int (*update_va_mapping) (struct domain *d, l1_pgentry_t pte);
> > > ...
> > > > +static inline int xsm_update_va_mapping(struct domain *d,
> > > > l1_pgentry_t pte)
> > > > +{
> > > > +    return xsm_call(update_va_mapping(d, pte));
> > > > +}
> > > 
> > >    Shouldn't we be using a more opaque type here?  l1_pgentry_t is
> > > rather arch specific.  The implementation of update_va_mapping() in
> > > flask is also very x86 centric.  Thanks,
> > > 
> > 
> > For the moment, I would say no since this hook is in the
> > do_update_va_mapping hypercall which currently exists only in the x86
> > bits of xen.  The flask module and XSM code are also bounded by ifdefs,
> > so for non-x86 archs it is not included.  Should other archs ever
> > develop equivalent funcs, I'd be happy to update this hook to a more
> > generic interface to accommodate these archs and reduce the number of
> > arch specific hooks.
> 
> Hi George,
> 
>    Then perhaps xsm_update_va_mapping() and it's prototype need to be
> put in #ifdef x86 code (it's not currently).  Thanks,
> 
You are correct, I'll post a patch.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.