Re: [integrity:next-integrity-testing 5/5] security/integrity/ima/ima_asymmetric_keys.c:53:6: error: redefinition of 'ima_init_key_queue'

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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