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?
Instead can CONFIG_ASYMMETRIC_KEY_TYPE be used to enable key measurement
code in IMA?
crypto\asymmetric_keys\Kconfig
# SPDX-License-Identifier: GPL-2.0
menuconfig ASYMMETRIC_KEY_TYPE
bool "Asymmetric (public-key cryptographic) key type"
depends on KEYS
help
This option provides support for a key type that holds the
data for the asymmetric keys used for public key cryptographic
operations such as encryption, decryption, signature
generation and signature verification.
thanks,
-lakshmi
