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
On Sat, Jun 22, 2013 at 6:07 PM, M A Young <m.a.young@durham.ac.uk> 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 YoungI 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
Steven, thank you for adding the docs. I may have a go it it on Monday to prettify it (you may have noticed that I made CSS changes to change the wiki look and feel and bring it in line with the main site) Lars On Sun, Jun 23, 2013 at 7:29 AM, Steven Maresca <steve@zentific.com> wrote:> On Sat, Jun 22, 2013 at 6:07 PM, M A Young <m.a.young@durham.ac.uk> 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@lists.xen.org > http://lists.xen.org/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Sun, 23 Jun 2013, Steven Maresca wrote:> On Sat, Jun 22, 2013 at 6:07 PM, M A Young <m.a.young@durham.ac.uk> 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