[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


 


Rackspace

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