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;
From:   Stephan Mueller <smueller@chronox.de>
To:     Alexander Dahl <ada@thorsis.com>
Cc:     linux-crypto@vger.kernel.org
Subject: Re: jitterentropy_rng on armv5 embedded target
Date:   Fri, 08 May 2020 13:58:14 +0200
Message-ID: <6309135.Bj5FvMsAKG@tauon.chronox.de>
In-Reply-To: <2567555.LKkejuagh6@ada>
References: <2567555.LKkejuagh6@ada>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Am Freitag, 8. Mai 2020, 13:40:08 CEST schrieb Alexander Dahl:

Hi Alexander,

> Hello,
>=20
> after upgrading OpenSSL to 1.1.1g on an armv5 based embedded target I had=
 a
> deeper look into entropy generation for that device and stumbled over the=
 in
> kernel 'jitterentropy_rng' module.
>=20
> As far as I understood it's supposed to do the same as the well known
> 'haveged' or the userspace daemon 'jitterentropy-rngd' by Stephan M=FCller
> [1], right?

Yes, precisely. In fact, it is the identical code base of the core=20
functionality that both the kernel and the jitterentropy-rngd uses. See the=
=20
comment at the top of the kernel source code.

> (Although those daemons would solve my problem, I currently try
> to avoid them, because memory on my platform is very restricted and every
> additional running userspace process costs at least around 1 MB.)

If you compile it and you also have AF_ALG for RNGs compiled, you can use i=
t=20
through the AF_ALG interface (see [1] for a library). But IMHO if you are=20
space-constrained, you do not want that code.

Rather use the jitterentropy-library from [2] and link it straight from you=
r=20
application.
>=20
> If so, then how is it supposed to be set up?=20

It is intended for in-kernel purposes (namely to seed its DRBG).

> I built it for 4.9.x LTS, but
> after loading it with 'modprobe' I see nothing in the kernel log and ther=
e's
> no significant change in /proc/sys/kernel/random/entropy_avail (stays well
> below 100 most of the time). Isn't that module supposed to gather entropy
> from cpu timing jitter?
>=20
> Puzzled
> Alex
>=20
> [1] https://www.chronox.de/jent.html

[1] https://www.chronox.de/libkcapi.html

[2] https://github.com/smuellerDD/jitterentropy-library


Ciao
Stephan