linux-kernel - Re: kdf108_init() takes over 250 ms

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] [day] [month] [year] [list]

Message-ID: <4585b0e7-7172-476d-8cd9-012ca65daa9b@molgen.mpg.de>
Date: Sun, 29 Jun 2025 22:06:41 +0200
From: Paul Menzel <pmenzel@...gen.mpg.de>
To: Stephan Mueller <smueller@...onox.de>,
 Tim Chen <tim.c.chen@...ux.intel.com>, Robert Elliott <elliott@....com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
 "David S. Miller" <davem@...emloft.net>, linux-crypto@...r.kernel.org,
 LKML <linux-kernel@...r.kernel.org>
Subject: Re: kdf108_init() takes over 250 ms

Dear Stephan, dear Robert,


Am 26.08.22 um 09:47 schrieb Stephan Mueller:
> Am Dienstag, 23. August 2022, 22:10:01 CEST schrieb Elliott, Robert (Servers):

>>> -----Original Message-----
>>> From: Paul Menzel <pmenzel@...gen.mpg.de>
>>> Sent: Tuesday, August 23, 2022 9:52 AM

[…]

>>> On the Dell XPS 13 9370 with Debian sid/unstable, I noticed with Linux
>>> 5.18.16, that  `crypto_kdf108_init()` takes 263 ms to run even with
>>> disabled self-tests:
>>>
>>
>> ...
>>
>>> [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.18.0-4-amd64
>>> root=UUID=56f398e0-1e25-4fda-aa9f-611dece4b333 ro quiet
>>> module_blacklist=psmouse initcall_debug log_buf_len=4M cryptomgr.notests
>>
>> ...
>>
>>> [    0.272127] calling  crypto_kdf108_init+0x0/0x149 @ 1
>>> [    0.530787] Freeing initrd memory: 39332K
>>> [    0.534667] alg: self-tests disabled
>>> [    0.534701] alg: self-tests for CTR-KDF (hmac(sha256)) passed
>>> [    0.534703] initcall crypto_kdf108_init+0x0/0x149 returned 0 after 262573 usecs
>>
>> ...
>>
>>>
>>> With self-tests enabled it’s only less than a millisecond longer.
>>>
>>> ```
>>> [    0.282389] calling  crypto_kdf108_init+0x0/0x149 @ 1
>>> [    0.541096] Freeing initrd memory: 39332K
>>> [    0.545674] alg: self-tests for CTR-KDF (hmac(sha256)) passed
>>> [    0.545676] initcall crypto_kdf108_init+0x0/0x149 returned 0 after 263284 usecs
>>> ```
>>
>>
>> crypto_kdf108_init() call its self-test function directly rather
>> that alg_test(), which implements that notests flag. Maybe it
>> should go through alg_test().
> 
> You are right that it does not uses the alg_test. This is because the KDF is
> just a helper and not implemented as a template. I initially wanted and
> provided a patch that turns the KDFs into templates which then would be able
> to go though alg_test. It was not accepted, but instead only service functions
> where accepted.
> 
> The reason for not accepting the template approach was that a complete new API
> is needed to accommodate the KDFs. Initially I called the API "rng" because a
> KDF and a PRNG are very very similar in nature: they take an arbitrary string
> as input (the seed/key/personalization/additional info/label string) and
> provide an arbitrary output (mathematically you can even use both
> interchangeably for the same purposes - although cryptographically speaking
> you do not want that). As this concept cannot be covered with the existing
> APIs, a KDF cannot be rolled into those existing APIs as template. Side note:
> the same question around such new API will appear as soon as somebody asks for
> SHAKE to be added.
> 
> A low hanging fruit would be to also deactivate the KDF test when the notest
> option is selected.
> 
>> Outside of that, check that Tim's x86-optimized SHA-256 module
>> is loaded, so it is used rather than the generic implementation.
>> One my system, that improves the kdf108 initialization time
>> from 1.4 s to 0.38 s:
>>
>> With sha256_generic:
>>    initcall sha256_generic_mod_init+0x0/0x16 returned 0 after 0 usecs
>>    ...
>>    initcall crypto_kdf108_init+0x0/0x18d returned 0 after 1425640 usecs
>>
>> With sha256_ssse3 (using its AVX2 implementation):
>>    initcall sha256_ssse3_mod_init+0x0/0x1bf returned 0 after 12148 usecs
>>    ...
>>    initcall crypto_kdf108_init+0x0/0x153 returned 0 after 382799 usecs
>>
>> That's controlled by CONFIG_CRYPTO_SHA256_SSSE3.
> 
> The test is performed during kernel boot time with the available
> implementation - the self test uses "hmac(sha256)". If the AVX2 is not
> registered at that time with the kernel crypto API, it will not be available
> for use. But it is not possible to hard-code the use of the AVX implementation
> or any other implementation as it is not guaranteed to be present.
> 
> The issue would be alleviated it would go through alg_test though.
As I didn’t notice this, or forgot it, for the record, this was 
addressed by Eric Biggers in commit 0bf365c0efdd ("crypto: kdf - skip 
self-test when tests disabled"), that first shows up in Linux v6.2-rc1.


Kind regards,

Paul