On Sun, 2020-01-05 at 09:57 -0800, Lakshmi Ramasubramanian wrote:
> On 1/5/2020 1:00 AM, kbuild test robot wrote:
>
> >
> > > > security/integrity/ima/ima_asymmetric_keys.c:53:6: error:
> > > > redefinition of 'ima_init_key_queue'
> >
> > void ima_init_key_queue(void)
> > ^~~~~~~~~~~~~~~~~~
> > In file included from
> > security/integrity/ima/ima_asymmetric_keys.c:16:0:
> > security/integrity/ima/ima.h:222:20: note: previous definition
> > of 'ima_init_key_queue' was here
> > static inline void ima_init_key_queue(void) {}
>
> In the given config file the following configs are specified
>
> CONFIG_IMA=y
> CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=m
>
> If CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE is selected
> ima_asymmetric_keys.c file is built and linked (as given in the
> Makefile). ima_init_key_queue() is declared in ima.h
>
> But if CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE is not selected
> ima_asymmetric_keys.c is not built. ima_init_key_queue() is declared
> as an empty function (static inline in ima.h)
>
> #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
