Hi all,
After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:
x86_64-linux-gnu-ld: security/keys/big_key.o: in function `big_key_read':
big_key.c:(.text+0x562): undefined reference to `chacha20poly1305_decrypt'
x86_64-linux-gnu-ld: security/keys/big_key.o: in function `big_key_preparse':
big_key.c:(.text+0x825): undefined reference to `chacha20poly1305_encrypt'
Caused by commit
e0a715753a88 ("security/keys: rewrite big_key crypto to use library interface")
I have used the version from next-20200512 again tdoay.
--
Cheers,
Stephen Rothwell
Stephen Rothwell [off-list ref] wrote:
After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:
x86_64-linux-gnu-ld: security/keys/big_key.o: in function `big_key_read':
big_key.c:(.text+0x562): undefined reference to `chacha20poly1305_decrypt'
x86_64-linux-gnu-ld: security/keys/big_key.o: in function `big_key_preparse':
big_key.c:(.text+0x825): undefined reference to `chacha20poly1305_encrypt'
Caused by commit
e0a715753a88 ("security/keys: rewrite big_key crypto to use library interface")
I have used the version from next-20200512 again tdoay.
Blech. Yeah. "depends on" doesn't work either. The problem actually lies
within the Kconfig framework. It doesn't know how to handle a bool depending
on a tristate.
So the issue is that with Jason's patch, we now have:
config BIG_KEYS
bool "Large payload keys"
depends on KEYS
depends on TMPFS
depends on CRYPTO_LIB_CHACHA20POLY1305
...
config CRYPTO_LIB_CHACHA20POLY1305
tristate "ChaCha20-Poly1305 AEAD support (8-byte nonce library version)"
depends on CRYPTO_ARCH_HAVE_LIB_CHACHA || !CRYPTO_ARCH_HAVE_LIB_CHACHA
depends on CRYPTO_ARCH_HAVE_LIB_POLY1305 || !CRYPTO_ARCH_HAVE_LIB_POLY1305
select CRYPTO_LIB_CHACHA
select CRYPTO_LIB_POLY1305
But you're allowed to set CONFIG_CRYPTO_LIB_CHACHA20POLY1305=m.
Using "select" instead can lead to warnings about circular dependencies and,
in any case, doesn't propagate the selection up the tree.
Also, in this case, having BIG_KEYS select everything isn't practical as
CRYPTO_LIB_CHACHA20POLY1305 has a logical-XOR in its depends on.
I think one or more of the following things need to happen:
(1) The configurator needs to give an error if it detects this.
(2) The configurator needs to propagate select rootwards.
(3) The configurator needs to propagate "=y" rootwards over depends on,
prohibiting "=m".
(4) The BIG_KEYS config needs to switch to a tristate.[*]
Do we have a preference?
David
[*] Note there have been situations where switching to a tristate isn't
technically an option because the dependency target was required during
boot (crypto used by module checking, for example), but we've just had to
work around it and hope whoever was configuring the kernel built
everything in.
On Mon, May 18, 2020 at 9:01 AM David Howells [off-list ref] wrote:
Blech. Yeah. "depends on" doesn't work either. The problem actually lies
within the Kconfig framework. It doesn't know how to handle a bool depending
on a tristate.
No problem with Kconfig. It knows exactly how to let a bool depend on
a tristate.
It's just that there are two different kinds of dependencies.
For example, the dependency can be a hard and absolute dependency
(linking doesn't work, or whatever), and then obviously built-in code
cannot be enabled if the thing it depends on is a loadable module.
But the dependency can also be a conceptual one: "This option doesn't
make sense unless that option is set". Then a bool can make sense even
if the other config is a modular one.
And Kconfig can deal with either situation just fine.
Do
depends on XYZ = y
or
depends on XYZ != n
to clarify the choice. One requires a hard dependency, the other
requires that the option just be enabled.
Now, if you just do "depends on XYZ", it allows a bool to be enabled
even for just a module (ie that second case). That makes sense for a
lot of "allow this feature in the module" kind of options, where it
would be pointless to even ask about a boolean feature if the parent
module isn't even enabled.
But that "depends on XYZ=y" is not uncommon. It basically says "this
option makes sense only when built in". Either because it requires it
for linking, or just because it doesn't work or make sense without it.
Linus