linux-kernel - Re: [PATCH v3 2/5] crypto: caam: Fix endless loop when RNG is already initialized

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]

Date:   Thu, 1 Feb 2018 12:16:51 +0000
From:   Horia Geantă <horia.geanta@....com>
To:     Bryan O'Donoghue <pure.logic@...us-software.ie>,
        Aymen Sghaier <aymen.sghaier@....com>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     Fabio Estevam <fabio.estevam@....com>, Peng Fan <peng.fan@....com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "lukas.auer@...ec.fraunhofer.de" <lukas.auer@...ec.fraunhofer.de>,
        "rui.silva@...aro.org" <rui.silva@...aro.org>,
        "ryan.harkin@...aro.org" <ryan.harkin@...aro.org>,
        Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH v3 2/5] crypto: caam: Fix endless loop when RNG is already
 initialized

On 1/31/2018 4:00 AM, Bryan O'Donoghue wrote:
> commit 1005bccd7a4a ("crypto: caam - enable instantiation of all RNG4 state
> handles") introduces a control when incrementing ent_delay which contains
> the following comment above it:
> 
> /*
>  * If either SH were instantiated by somebody else
>  * (e.g. u-boot) then it is assumed that the entropy
>  * parameters are properly set and thus the function
>  * setting these (kick_trng(...)) is skipped.
>  * Also, if a handle was instantiated, do not change
>  * the TRNG parameters.
>  */
> 
> This is a problem observed when sec_init() has been run in u-boot and
> and TrustZone is enabled. We can fix this by instantiating all rng state
> handles in u-boot but, on the Kernel side we should ensure that this
> non-terminating path is dealt with.
> 
> Fixes: 1005bccd7a4a ("crypto: caam - enable instantiation of all RNG4 state
> handles")
> 
> Reported-by: Ryan Harkin <ryan.harkin@...aro.org>
> Cc: "Horia Geantă" <horia.geanta@....com>
> Cc: Aymen Sghaier <aymen.sghaier@....com>
> Cc: Fabio Estevam <fabio.estevam@....com>
> Cc: Peng Fan <peng.fan@....com>
> Cc: "David S. Miller" <davem@...emloft.net>
> Cc: Lukas Auer <lukas.auer@...ec.fraunhofer.de>
> Cc: <stable@...r.kernel.org> # 4.12+
> Signed-off-by: Bryan O'Donoghue <pure.logic@...us-software.ie>
> ---
>  drivers/crypto/caam/ctrl.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
> index 98986d3..0a1e96b 100644
> --- a/drivers/crypto/caam/ctrl.c
> +++ b/drivers/crypto/caam/ctrl.c
> @@ -704,7 +704,10 @@ static int caam_probe(struct platform_device *pdev)
>  					 ent_delay);
>  				kick_trng(pdev, ent_delay);
>  				ent_delay += 400;
> +			} else if (ctrlpriv->rng4_sh_init && inst_handles) {
> +				ent_delay += 400;
>  			}
If both RNG state handles are initialized before kernel runs, then
instantiate_rng() should be a no-op and return 0, which is enough to exit the
loop: while ((ret == -EAGAIN) && (ent_delay < RTSDCTL_ENT_DLY_MAX))

If the loop cannot exit based on value of "ret" != -EAGAIN, then it means
caam_probe() will eventually fail due to ret == -EAGAIN:
	if (ret) {
		dev_err(dev, "failed to instantiate RNG");
		goto caam_remove;
	}

Please provide more details, so that the root cause is found and fixed.
For e.g. what is the value of RDSTA (RNG DRNG Status register @0x6C0):
-before & after u-boot initializes RNG
-as seen by kernel during caam_probe()
Also provide related error messages displayed during boot.

Thanks,
Horia