linux-kernel - Re: [security] d3b04a4398: WARNING:at_crypto/kdf_sp800108.c:#crypto_kdf108

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3737408.Lz6Wf2Li4r@tauon.chronox.de>
Date:   Fri, 10 Dec 2021 15:16:34 +0100
From:   Stephan Mueller <smueller@...onox.de>
To:     Yujie Liu <yujie.liu@...el.com>,
        Herbert Xu <herbert@...dor.apana.org.au>
Cc:     Mat Martineau <mathew.j.martineau@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        lkp@...ts.01.org, lkp@...el.com,
        "Sang, Oliver" <oliver.sang@...el.com>
Subject: Re: [security] d3b04a4398: WARNING:at_crypto/kdf_sp800108.c:#crypto_kdf108_init

Am Freitag, 10. Dezember 2021, 03:54:32 CET schrieb Yujie Liu:

Hi Yujie, Herbert,

> This table shows that we have tested commit d3b04a4398("security: DH - use
> KDF implementation from crypto API") for several runs of boot test in qemu
> but got 100% bad result. We have also tested its parent commit (i.e. commit
> d792134423 "security: DH - remove dead code for zero padding") and all the
> runs got 100% good result. So this is not a random issue.
> 
> > I am unable to reproduce it with i386 and clang-13. I can also not
> > reproduce it with GCC.
> 
> We have tested the i386 kernel built by gcc-9 or clang-14, and confirmed
> both of them can reproduce this issue reliably.
> 
> Please be sure to follow the reproduce steps in original report mail. The
> full reproduce log is attached.

Thank you for your response. The key log info is:

alg: self-tests for CTR-KDF (hmac(sha256)) failed (rc=-12)

And I finally see what the problem is: you selected SHA-256 as module but the 
KDF implementation is selected to be statically linked.

So the KDF self test tries to allocate the SHA-256 algorithm and fails which 
causes the ENOMEM error.


Herbert, what is your preference in handling this:

- we could SELECT CRYPTO_SHA256 when the KDF is compiled. This would only be 
necessary to satisfy the self test. Yet, there is no guarantee that SHA-256 
would truly be needed because the DH code that calls the KDF obtains the 
reference to the hash from user space. In the end we could hard compile a 
crypto algorithm into the kernel that may never be used.

- we could relax the KDF self test a bit and could prevent the self test being 
executed if we get an ENOENT back during the algorithm allocation. But that 
would imply that the KDF self test would never be executed. Even when SHA-256 
is compiled as module and insmod'ed at a later time the KDF self test is not 
executed as it is only executed from the __init function.


I would prefer to consider the first option to also statically compile 
SHA-256.

Ciao
Stephan