Re: Can KEY_DH_OPERATIONS become tristate? (was: Re: Kernel 5.3.0 stuck during boot on Amiga)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi David,

On Wed, Sep 18, 2019 at 6:43 PM David Howells <dhowells@xxxxxxxxxx> wrote:
Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
TL;DR: CONFIG_CRYPTO_DH=y is reported to cause boot delays of several
minutes on old and slow machines.

Why is it doing that?  It doesn't do anything unless it is called, so
something must be calling it.

I don't know.  Enabling initcall_debug shows that dh_init() takes a very long
time.

Ah...  The bit that handles keyctl_dh_compute() doesn't do anything unless
asked, but the bit in the crypto layer that does dh does (ie. dh_init()).  I
guess it's doing some sort of self-test, but I can't see how it effects that.
I think you need to consult the author/maintainer of crypto/dh.c.

Apparently the Debian kernel config had not enabled
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS, so all crypto tests
were run at boot time :-(

It might be possible to make CONFIG_KEY_DH_OPERATIONS not depend on
CONFIG_CRYPTO_DH and have crypto_alloc_kpp() load the *crypto* part on
demand.  Failing that, I can look into demand-loading keyctl operations.

Regardless, it may be a good idea to make KEY_DH_OPERATIONS tristate
one day, so enabling wireless as a module doesn't force CONFIG_CRYPTO_DH
builtin.

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds



[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux