Alex Williamson
2007-Sep-04 14:07 UTC
[Xen-devel] Re: [Xen-staging] [xen-unstable] Xen Security Modules: XSM
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, Alex -- Alex Williamson HP Open Source & Linux Org. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George S. Coker, II
2007-Sep-04 17:22 UTC
[Xen-devel] Re: [Xen-staging] [xen-unstable] Xen Security Modules: XSM
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. George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2007-Sep-04 17:28 UTC
[Xen-devel] Re: [Xen-staging] [xen-unstable] Xen Security Modules: XSM
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, Alex -- Alex Williamson HP Open Source & Linux Org. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George S. Coker, II
2007-Sep-04 17:36 UTC
[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@lists.xensource.com http://lists.xensource.com/xen-devel