|
|
|
|
|
|
|
|
|
|
xense-devel
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
|
|
|
|
|