Re: [Xen-devel] [PATCH 17/17] xsm: add a default policy to .init.data

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 06/24/2016 01:46 PM, Konrad Rzeszutek Wilk wrote:
> > > > I can remove the HAS_CHECKPOLICY check completely and make the call to
> > > > checkpolicy only conditional on the Kconfig option.  I think this is
> > > > less complicated than stopping the compile one step above the invocation
> > > > of checkpolicy, and probably just as informative (and better, if the
> > > > detection heuristic ever breaks).
> > > I actually like the way you have it - with the checkpolicy check determining
> > > whether the Kconfig option for XSM is shown or not.
> > Is that possible?  That's not what I have; the check I have only determines
> > if the Kconfig option does anything or not, it is still visible regardless.
> Totally!
>
> See 95111a94f0168699d5154c7a25bd33865559e2c xsplice: Stacking build-id 
> dependency checking.
>
> Thanks.
Ah, I hadn't considered setting the variable in the top-level Config.mk.
If I were to add the HAS_CHECKPOLICY check there, I think it would make
sense to have it adjust the default value of CONFIG_XSM_POLICY, but
not hide the option.  If someone deliberately enables the option, then
having the compile error show up is less confusing than the current
method where it gets enabled when only selecting XSM.

Anyway, since checkpolicy is required to make use of FLASK, anyone who
currently enables XSM is going to need to install it at some point: either
in the hypervisor compile for the built-in policy or the tools compile for
the bootloader- or dom0-provided policy.  Having the error show up sooner
is not all that much of a problem.  This would change if XSM were to be
enabled by default, because I would then expect "xsm enabled, flask disabled"
to become a more common case - and that does not require a policy.

--
Daniel De Graaf
National Security Agency

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