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

[Steven Maresca <steve@xxxxxxxxxxxx>]

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. On the other hand
> the configurations
>
> multiboot xen.gz
> module vmlinuz args
> module xenpolicy.24
> module initramfs.img
>
> and
>
> multiboot xen.gz
> module vmlinuz args
> module initramfs.img
> module xenpolicy.24
>
> do work. Should the first case work as well, or is the documentation wrong
> (or confusing)?
>
>         Michael Young

I think that's probably a documentation issue. I have updated the wiki
page with a more complete example of the grub configuration and added
some cautionary words about ordering -- thanks for that feedback.  Be
sure to add flask_enforcing=1 or =0 to the xen.gz parameters, too.

[ 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.

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel