linux-kernel - Re: [PATCH 2/5] crypto: hisilicon/sec - delete the print of fallback tfm application failure

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: <20210806083130.GA13132@gondor.apana.org.au>
Date:   Fri, 6 Aug 2021 16:31:30 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Kai Ye <yekai13@...wei.com>
Cc:     linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        wangzhou1@...ilicon.com
Subject: Re: [PATCH 2/5] crypto: hisilicon/sec - delete the print of fallback
 tfm application failure

On Sat, Jul 31, 2021 at 11:26:33AM +0800, Kai Ye wrote:
> Modify the print of information that might lead to user misunderstanding.
> Currently only XTS mode need the fallback tfm when using 192bit key.
> Others algs not need soft fallback tfm. So others algs can return
> directly.
> 
> Signed-off-by: Kai Ye <yekai13@...wei.com>
> ---
>  drivers/crypto/hisilicon/sec2/sec_crypto.c | 15 +++++++--------
>  1 file changed, 7 insertions(+), 8 deletions(-)

I don't think this is a good change.

> @@ -2032,13 +2032,12 @@ static int sec_skcipher_soft_crypto(struct sec_ctx *ctx,
>  				    struct skcipher_request *sreq, bool encrypt)
>  {
>  	struct sec_cipher_ctx *c_ctx = &ctx->c_ctx;
> +	SYNC_SKCIPHER_REQUEST_ON_STACK(subreq, c_ctx->fbtfm);
>  	struct device *dev = ctx->dev;
>  	int ret;
>  
> -	SYNC_SKCIPHER_REQUEST_ON_STACK(subreq, c_ctx->fbtfm);
> -
>  	if (!c_ctx->fbtfm) {
> -		dev_err(dev, "failed to check fallback tfm\n");
> +		dev_err(dev, "the soft tfm isn't supported in the current system.\n");

If we end up in this code path you'll be spamming the printk buffer
on every single request.  This is not acceptable.  At least rate limit
these messages.

Thanks,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt