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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 26 Aug 2022 09:47:17 +0200
From:   Stephan Mueller <smueller@...onox.de>
To:     Paul Menzel <pmenzel@...gen.mpg.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        "Elliott, Robert (Servers)" <elliott@....com>
Cc:     Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: kdf108_init() takes over 250 ms

Am Dienstag, 23. August 2022, 22:10:01 CEST schrieb Elliott, Robert (Servers):

Hi Robert,

> > -----Original Message-----
> > From: Paul Menzel <pmenzel@...gen.mpg.de>
> > Sent: Tuesday, August 23, 2022 9:52 AM
> > To: Stephan Müller <smueller@...onox.de>
> > 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: kdf108_init() takes over 250 ms
> > 
> > Dear Stephan,
> > 
> > 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.

> 
> 

Ciao
Stephan