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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Jun 24, 2016 at 02:02:42PM -0400, Daniel De Graaf wrote:
> 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.

Ah, that would work too and I believe satisfy Julien as well!
> 
> 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.

/me nods.
> 
> -- 
> Daniel De Graaf
> National Security Agency

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