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:   Fri, 2 Feb 2018 12:54:24 +0000
From:   "Auer, Lukas" <lukas.auer@...ec.fraunhofer.de>
To:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "aymen.sghaier@....com" <aymen.sghaier@....com>,
        "horia.geanta@....com" <horia.geanta@....com>,
        "pure.logic@...us-software.ie" <pure.logic@...us-software.ie>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>
CC:     "peng.fan@....com" <peng.fan@....com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "ryan.harkin@...aro.org" <ryan.harkin@...aro.org>,
        "fabio.estevam@....com" <fabio.estevam@....com>,
        "rui.silva@...aro.org" <rui.silva@...aro.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>
Subject: Re: [PATCH v3 2/5] crypto: caam: Fix endless loop when RNG is
 already initialized

On Fri, 2018-02-02 at 11:20 +0000, Bryan O'Donoghue wrote:
> On 01/02/18 12:16, Horia Geantă wrote:
> > 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;
> > 	}
> 
> For me it's an endless loop applying the first two
> 
> https://patchwork.ozlabs.org/patch/866460/
> https://patchwork.ozlabs.org/patch/866462/
> 
> but not this one
> 
> https://patchwork.ozlabs.org/patch/865890/
> 
> > Please provide more details, so that the root cause is found and
> > fixed.
> 
> np
> 
> ---
> bod

I think the problem lies in the instantiate_rng() function. If the
driver is unable to acquire DEC0 it'll return -ENODEV. This should
terminate the while loop in the probe function. However, the return
value is never checked and is instead overwritten with -EAGAIN, causing
the endless loop.

This problem only occurs if u-boot instantiates only one of the state
handles (ent_delay doesn't get incremented) and the kernel runs in non-
secure mode (DEC0 can't get acquired). Instantiating all state handles
in u-boot therefore fixes this problem. In addition, the return value
in instantiate_rng() should be handled correctly by including

if (ret)
	break;

right after "ret = run_descriptor_deco0(ctrldev, desc, &status);".

Thanks,
Lukas