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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 29.05.2020 11:55, George Dunlap wrote:
> 
> 
>> On May 29, 2020, at 9:52 AM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 27.05.2020 18:08, George Dunlap wrote:
>>>> On May 27, 2020, at 4:41 PM, Ian Jackson <ian.jackson@xxxxxxxxxx> 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.

Yes, all output files go into the build tree, to keep the source tree
clean. And .config is effectively an output file, despite it possibly
getting pre-populated into the build tree.

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

Hmm, yes, that's certainly an option. The intended behavior with
--no-xen-config would be of interest though: Just what it is
now, i.e. controlled by yet another configure option?

>> 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?

Something like "XSM_FLASK=y".

Jan