This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM

To: Chris Wright <chrisw@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
From: James Morris <jmorris@xxxxxxxxxx>
Date: Fri, 1 Sep 2006 15:46:49 -0400 (EDT)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 01 Sep 2006 12:47:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060901185502.GC21066@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

Xense-devel mailing list