Re: Xen XSM/FLASK policy, grub defaults, etc.

[George Dunlap <George.Dunlap@citrix.com>]

> On May 29, 2020, at 9:52 AM, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 27.05.2020 18:08, George Dunlap wrote:
>>> On May 27, 2020, at 4:41 PM, Ian Jackson <ian.jackson@citrix.com> wrote:
>>> 2. Xen should disable the XSM policy build when FLASK is disabled.
>>> This is unfortunately not so simple because the XSM policy build is a
>>> tools option and FLASK is a Xen option and the configuration systems
>>> are disjoint.  But at the very least a default build, which has no XSM
>>> support, should not build an XSM policy file either.
>> 
>> A simple thing to do here would be to have the flask policy controlled by a configure --flask option.  If neither --flask nor --no-flask is specified, we could maybe have configure also check the contents of xen/.config to see if CONFIG_XSM_FLASK is enabled?
> 
> But that's creating a chicken-and-egg problem: There's no ordering
> between the tools/ and xen/ builds. xen/ may not be built at all,
> and this is going to become increasingly likely once the xen/ part
> of the tree supports out-of-tree builds (at least I'll switch most
> of my build trees to that model as soon as it's available).

Do out-of-tree builds put the .config out of tree as well?  If so, yes, that would definitely limit the usefulness of this idea.

My suggestion was based on the idea that a “typical” build *which might enable XSM* would look like this:

1. Run ‘make menuconfig’ (or something like it) in xen/

2. Run ./configure at the toplevel

3. Do the full build.

But looking back at it, there’s no particular reason that someone coming to build Xen might expect to do things in that order rather than #1.

It might make sense to simply declare that the tools depend on the xen config, and modifying ./configure to represent that:

1. Add a `—xen-config=` option to configure telling it where to look for the xen config; if that’s not specified, look for a specific shell variable saying where the Xen tree is; if that’s not available, looking in the current tree.

2. Have ./configure fail by default if it can’t find a .config, unless —no-xen-config is specified.

> Do we perhaps need to resort to a make command line option, usable
> at the top level as well as for major subtree builds, and being
> honored (as long as set either way, falling back to current
> behavior if unset) by both ./configure and the hypervisor's
> Kconfig?

What kind of command-line option did you have in mind?

 -George