On Sun, 2020-01-05 at 10:56 -0800, Lakshmi Ramasubramanian wrote:
> On 1/5/2020 10:15 AM, James Bottomley wrote:
>
> > > #ifdef CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> > > void ima_init_key_queue(void);
> > > #else
> > > static inline void ima_init_key_queue(void) {}
> > > #endif /* CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE */
> > >
> > > If I understand the reported build error, it looks like
> > > CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE was disabled first and then
> > > enabled later - in the same build sequence.
> > >
> > > Is that correct?
> >
> > I don't think so. The specific problem is that
> > ASYMMETRIC_PUBLIC_KEY_SUBTYPE is defined as a tristate in
> > crypto/asymmetric_keys/Kconfig, so the above m setting for it is
> > perfectly legal regardless of the IMA setting. This line you
> > introduced to the Makefile:
> >
> > obj-$(CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE) +=
> > ima_asymmetric_keys.o
> >
> > Then causes ima_asymmetric_keys.o to be added to obj-m causing the
> > kernel to think it's building it as a module.
> >
> > To fix this, I think you have to force
> > ASYMMETRIC_PUBLIC_KEY_SUBTYPE to
> > be built in if IMA is.
> >
> > James
>
> Thanks for the info James. That explains the other error reported
> earlier - ima_asymmetric_keys.c being built as a kernel module.
>
> Since IMA can currently be enabled without enabling the KEYS
> subsystem, I feel forcing ASYMMETRIC_PUBLIC_KEY_SUBTYPE to be built
> if IMA is may not be safe. Right?
In general trying to force via select can have unintended consequences
for options with large dependencies, yes.
> Instead can CONFIG_ASYMMETRIC_KEY_TYPE be used to enable key
> measurement code in IMA?
Well, yes, you just need to condition the build of ima_asymmetric_keys
on a boolean instead of a tristate, so you introduce an intermediate
one:
config IMA_ASYMMETRIC_KEYS
bool
default y
depends on ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y
James
