netdev - Re: [PATCH net v2] esp: select CRYPTO

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: <20200605180023.GF1373@sol.localdomain>
Date:   Fri, 5 Jun 2020 11:00:23 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     netdev@...r.kernel.org
Cc:     linux-crypto@...r.kernel.org, Corentin Labbe <clabbe@...libre.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: [PATCH net v2] esp: select CRYPTO_SEQIV when useful

On Fri, Jun 05, 2020 at 10:39:31AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@...gle.com>
> 
> CRYPTO_CTR no longer selects CRYPTO_SEQIV, which breaks IPsec for users
> who need any of the algorithms that use seqiv.  These users now would
> need to explicitly enable CRYPTO_SEQIV.
> 
> There doesn't seem to be a clear rule on what algorithms the IPsec
> options (INET_ESP and INET6_ESP) actually select, as apparently none is
> *always* required.  They currently select just a particular subset,
> along with CRYPTO_ECHAINIV which is the other IV generator template.
> 
> As a compromise between too many and too few selections, select
> CRYPTO_SEQIV if either CRYPTO_CTR or CRYPTO_CHACHA20POLY1305 is enabled.
> These are the algorithms that can use seqiv for IPsec.  (Note: GCM and
> CCM can too, but those both use CTR.)
> 
> Fixes: f23efcbcc523 ("crypto: ctr - no longer needs CRYPTO_SEQIV")
> Cc: Corentin Labbe <clabbe@...libre.com>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Cc: Herbert Xu <herbert@...dor.apana.org.au>
> Cc: Steffen Klassert <steffen.klassert@...unet.com>
> Signed-off-by: Eric Biggers <ebiggers@...gle.com>
> ---
> 
> v2: added the 'if' condition and updated commit message
> 
>  net/ipv4/Kconfig | 1 +
>  net/ipv6/Kconfig | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> index 23ba5045e3d3..6520b30883cf 100644
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
> @@ -361,6 +361,7 @@ config INET_ESP
>  	select CRYPTO_SHA1
>  	select CRYPTO_DES
>  	select CRYPTO_ECHAINIV
> +	select CRYPTO_SEQIV if CRYPTO_CTR || CRYPTO_CHACHA20POLY1305
>  	---help---
>  	  Support for IPsec ESP.
>  

Oops, this doesn't actually work:

scripts/kconfig/conf  --olddefconfig Kconfig
crypto/Kconfig:1799:error: recursive dependency detected!
crypto/Kconfig:1799:	symbol CRYPTO_DRBG_MENU is selected by CRYPTO_RNG_DEFAULT
crypto/Kconfig:83:	symbol CRYPTO_RNG_DEFAULT is selected by CRYPTO_SEQIV
crypto/Kconfig:330:	symbol CRYPTO_SEQIV is selected by CRYPTO_CTR
crypto/Kconfig:370:	symbol CRYPTO_CTR is selected by CRYPTO_DRBG_CTR
crypto/Kconfig:1819:	symbol CRYPTO_DRBG_CTR depends on CRYPTO_DRBG_MENU
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"


I guess we need to go with v1 (which just had 'select CRYPTO_SEQIV'),
or else make users explicitly select CRYPTO_SEQIV?

- Eric