Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <f9e4f7269c93306784e9106f4eb8a6c874973143.camel@pengutronix.de>
Subject: CAAM RNG trouble
From:   Lucas Stach <l.stach@pengutronix.de>
To:     Horia =?UTF-8?Q?Geant=C4=83?= <horia.geanta@nxp.com>,
        Aymen Sghaier <aymen.sghaier@nxp.com>,
        Alexandru Porosanu <alexandru.porosanu@nxp.com>
Cc:     linux-crypto@vger.kernel.org, kernel@pengutronix.de
Date:   Mon, 14 Dec 2020 20:00:24 +0100
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.1 (3.38.1-1.fc33) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi all,

I've been looking into a CAAM RNG issue for a while, where I could need
some input from people knowing the CAAM hardware better than I do.
Basically the issue is that on some i.MX6 units the RNG functionality
sometimes fails with this error:
caam_jr 2101000.jr0: 20003c5b: CCB: desc idx 60: RNG: Hardware error.

I can tell that it is related to the entropy delay. On all failing
units the RNG4 gets instantiated with the default entropy delay of
3200. If I dial up the delay to 3600 or 4000 the RNG works reliably. As
a negative test I changed the initial delay to 400. With this change
all units are able to successfully instantiate the RNG handles at an
entropy delay of 2000 or 2400, but then reliably fail at getting random
data with the error shown above. I guess the issue is related to
prediction resistance on the handles, which causes the PRNG to be re-
seeded from the TRNG fairly often.

Now I don't have a good idea on how to arrive at a reliably working
entropy delay setting, as apparently the simple "are we able to
instantiate the handle" check is not enough to actually guarantee a
working RNG setup. Any suggestions?

Regards,
Lucas