Everyone:
This series is a continuation of original [discussion]. I don't know
if what's in the series is enough to use CAAMs HWRNG system wide, but
I am hoping that with enough iterations and feedback it will be.
Feedback is welcome!
Thanks,
Andrey Smirnov
[discussion] https://patchwork.kernel.org/patch/9850669/
Andrey Smirnov (3):
crypto: caam - RNG4 TRNG errata
crypto: caam - enable prediction resistance in HRWNG
crypto: caam - set hwrng quality level
drivers/crypto/caam/caamrng.c | 4 +++-
drivers/crypto/caam/ctrl.c | 19 +++++++++++++------
drivers/crypto/caam/desc.h | 2 ++
drivers/crypto/caam/regs.h | 7 +++++--
4 files changed, 23 insertions(+), 9 deletions(-)
--
2.21.0
Set high quality to let the HWRNG framework automatically use it.
Signed-off-by: Oleksij Rempel <[email protected]>
Signed-off-by: Andrey Smirnov <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: Horia Geantă <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Iuliana Prodan <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
drivers/crypto/caam/caamrng.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
index 6dde8ae3cd9b..23a573ea6cdb 100644
--- a/drivers/crypto/caam/caamrng.c
+++ b/drivers/crypto/caam/caamrng.c
@@ -299,6 +299,7 @@ static struct hwrng caam_rng = {
.name = "rng-caam",
.cleanup = caam_cleanup,
.read = caam_read,
+ .quality = 999,
};
void caam_rng_exit(void)
--
2.21.0
On Di, 2019-10-29 at 09:29 -0700, Andrey Smirnov wrote:
> Everyone:
>
> This series is a continuation of original [discussion]. I don't know
> if what's in the series is enough to use CAAMs HWRNG system wide, but
> I am hoping that with enough iterations and feedback it will be.
>
> Feedback is welcome!
I'm not sure if we can ever use the job based RNG interface to hook it
up to the Linux HWRNG interface. After all the job based RNG interface
is always a DRNG, which only gets seeded by the TRNG. The reseed
interval is given in number of clock cycles, so there is no clear
correlation between really true random input bits and the number of
DRNG output bits.
I've hacked up some proof of concept code which uses the TRNG access in
the control interface to get the raw TRNG random bits. This seems to
yield about 6400 bit/s of true entropy. It may be better to use this
interface to hook up to the Linux HWRNG framework.
Regards,
Lucas
On Tue, Oct 29, 2019 at 9:43 AM Lucas Stach <[email protected]> wrote:
>
> On Di, 2019-10-29 at 09:29 -0700, Andrey Smirnov wrote:
> > Everyone:
> >
> > This series is a continuation of original [discussion]. I don't know
> > if what's in the series is enough to use CAAMs HWRNG system wide, but
> > I am hoping that with enough iterations and feedback it will be.
> >
> > Feedback is welcome!
>
> I'm not sure if we can ever use the job based RNG interface to hook it
> up to the Linux HWRNG interface. After all the job based RNG interface
> is always a DRNG, which only gets seeded by the TRNG. The reseed
> interval is given in number of clock cycles, so there is no clear
> correlation between really true random input bits and the number of
> DRNG output bits.
>
Doesn't enabling prediction resistance gives us that correlation? E.g.
that every time new random data is generated, DRNG is reseeded? I am
assuming even if this is true we'd have to significantly limit
generated data length (< seed length?), so maybe what you propose
below is still simpler.
> I've hacked up some proof of concept code which uses the TRNG access in
> the control interface to get the raw TRNG random bits. This seems to
> yield about 6400 bit/s of true entropy. It may be better to use this
> interface to hook up to the Linux HWRNG framework.
>
OK, I'll take a look into that and send out a v2 with results.
Thanks,
Andrey Smirnov
On Tue, Oct 29, 2019 at 09:29:13AM -0700, Andrey Smirnov wrote:
> Everyone:
>
> This series is a continuation of original [discussion]. I don't know
> if what's in the series is enough to use CAAMs HWRNG system wide, but
> I am hoping that with enough iterations and feedback it will be.
>
> Feedback is welcome!
>
> Thanks,
> Andrey Smirnov
>
> [discussion] https://patchwork.kernel.org/patch/9850669/
>
> Andrey Smirnov (3):
> crypto: caam - RNG4 TRNG errata
> crypto: caam - enable prediction resistance in HRWNG
> crypto: caam - set hwrng quality level
>
> drivers/crypto/caam/caamrng.c | 4 +++-
> drivers/crypto/caam/ctrl.c | 19 +++++++++++++------
> drivers/crypto/caam/desc.h | 2 ++
> drivers/crypto/caam/regs.h | 7 +++++--
> 4 files changed, 23 insertions(+), 9 deletions(-)
All applied. Thanks.
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Nov 8, 2019 at 7:19 AM Herbert Xu <[email protected]> wrote:
>
> On Tue, Oct 29, 2019 at 12:58:24PM -0700, Andrey Smirnov wrote:
> >
> > > I'm not sure if we can ever use the job based RNG interface to hook it
> > > up to the Linux HWRNG interface. After all the job based RNG interface
> > > is always a DRNG, which only gets seeded by the TRNG. The reseed
> > > interval is given in number of clock cycles, so there is no clear
> > > correlation between really true random input bits and the number of
> > > DRNG output bits.
> >
> > Doesn't enabling prediction resistance gives us that correlation? E.g.
> > that every time new random data is generated, DRNG is reseeded? I am
> > assuming even if this is true we'd have to significantly limit
> > generated data length (< seed length?), so maybe what you propose
> > below is still simpler.
>
> Prediction resistance should be sufficient in general. However,
> is the prediction resistance reseeding done in real time?
>
If I am reading the datasheet right reseeding should be done every
time CAAM is asked to generated random data.
> > > I've hacked up some proof of concept code which uses the TRNG access in
> > > the control interface to get the raw TRNG random bits. This seems to
> > > yield about 6400 bit/s of true entropy. It may be better to use this
> > > interface to hook up to the Linux HWRNG framework.
> >
> > OK, I'll take a look into that and send out a v2 with results.
>
> I've backed out the patch-set for now but if we can clarify the
> prediction resistance implementation details then I'm happy to
> put it back in.
Even if prediction resistance is an acceptable approach, would it be
better to expose underlying TRNG and downgrade current CAAM hwrng code
to crypto rng API? If that's the best path forward, I am more than
happy to go that way in v2.
Thanks,
Andrey Smirnov
On Tue, Nov 12, 2019 at 07:13:02AM -0800, Andrey Smirnov wrote:
>
> If I am reading the datasheet right reseeding should be done every
> time CAAM is asked to generated random data.
If you can guarantee that everytime the driver reads n bytes from
the hardware, that the hardware is then reseeded with nbytes prior
to that read, then it should be good enough.
If the hardware only reseeds afterwards or reseeds with less than
n bytes then it is not sufficient.
> Even if prediction resistance is an acceptable approach, would it be
> better to expose underlying TRNG and downgrade current CAAM hwrng code
> to crypto rng API? If that's the best path forward, I am more than
> happy to go that way in v2.
If it offers true prediction resistance it should be good enough
to use the drivers/char/hw_random interface. Otherwise please
switch to the Crypto API RNG interface.
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt