[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Issue with XSM on xen 4.3 (rc5)

On Sun, 23 Jun 2013, Steven Maresca wrote:

On Sat, Jun 22, 2013 at 6:07 PM, M A Young <m.a.young@xxxxxxxxxxxx> wrote:
I have been testing enabling XSM/FLASK in xen-4.3.0-rc5 (with a view to
deciding whether or not to include it in the Fedora builds) and found an
issue which might be a bug or a documentation issue.

As I read the documentation ( http://wiki.xenproject.org/wiki/XSM and
http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt ) a grub2
configuration along the lines of

multiboot xen.gz
module xenpolicy.24
module vmlinuz args
module initramfs.img

should work, but it gives me a backtrace which looks the same as the one I
get if I miss out the xenpolicy.24 line completely.

[ Aside, re: enabling XSM for Fedora: yes please! ]

Under the hood, I don't think XSM cares about the placement of the
policy in terms of multiboot module order.  While initializing, XSM
inspects all of the multiboot modules, looking for a magic number
indicating that the module is a valid XSM policy. (see
xsm_policy_init() in xen/xsm/xsm_policy.c which was invoked by
xsm_init()). To be honest, I don't think we ever experimented with the
module order while building the XSM documentation.

That said, the x86 arch  __start_xen() has a comment "/* Dom0 kernel
is always first */" which makes me suspect here that this assumption
could be the one encountered. If you still have the backtrace(s) and
can share, that could help point in the right direction. I'll also try
the same on my end. It's definitely possible that a descriptive output
message is needed to suggest the solution, even while the
documentation could help to avoid such issues.

The bit is actually the rest of the line containing the comment you mention as it grabs the first module so xsm_init doesn't find it. The backtrace is actually from the flask code, and is what you get if the policy module is not found, as the flask code assumes it has found a module and tries to load it even if it hasn't.

My current plan for xen 4.3 in Fedora is to build it with XSM enabled, but with an extra patch so it reverts to disabled mode if no policy module is found. That would mean that current xen configurations would continue to work, and XSM could be turned on with suitable edits to the grub configuration file.

        Michael Young

Xen-devel mailing list



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