[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
On Fri, 1 Sep 2006, Chris Wright wrote: > > + int (*mmu_normal_update) (struct domain *d, intpte_t fpte); > > + > > + long (*__do_xsm_op) (GUEST_HANDLE(xsm_op_t) op); > > We very intentionally did not do this in LSM (or more to the point, > we did and it was soundly rejected). It's a free form way to extend the > hypercall interface, which in Linux is frowned upon. I agree with Chris here -- it's definitely an architectural issue to consider, in that you can end up with an arbitrary interface with weak semantics, which is prone to maintainability & security issues, tasteless abuse by third party code etc. > Of course, you don't have the various selinuxfs, /proc/<pid>/attr type > of interfaces in the hypervisor, but it's worth considering if there are > other possibilities (32/64-bit compat is an example of something which > is easily lost when pushing the hypercall interface down a layer into > the module). One interface possibility is some kind of extensible message passing channel (perhaps like Netlink). George, what did you have in mind as use-cases for this op? - James -- James Morris <jmorris@xxxxxxxxxx> _______________________________________________ Xense-devel mailing list Xense-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xense-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |