Re: [PATCH 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

On Fri, Nov 24, 2017 at 2:05 PM, Stephan Müller [off-list ref] wrote:

Am Freitag, 24. November 2017, 13:09:06 CET schrieb Krzysztof Kozlowski:

Hi Krzysztof,

quoted

quoted

quoted

1. I was rather thinking about extending existing exynos-rng.c [1] so
it would be using TRNG as seed for PRNG as this gives you much more
random data. Instead you developed totally separate driver which has
its own benefits - one can choose which interface he wants. Although
it is a little bit duplication.

As far as I can tell, these are two different devices. However, PRNG
shares hardware with the hash engine. Indeed there is a hardware to
connect TRNG and PRNG, but, IMHO, it might be hard to model that
dependency in kernel.

It should be as simple as setting few more registers in SSS module
(actually maybe just enabling TRNG_SEED_START in PRNG). You do not
have to model it in a kernel like connecting some hw_rng entity to
cryptoai's rng_alg. See the jitterentropy-kcapi.c. I understand that
in that case existing exynos-rng.c could expose two different RNG
devices - one PRNG based on user's seed and second TRNG (actually
TRNG+PRNG).

It does not seem difficult to model but the question is whether that
makes sense.

The usage strategy for the PRNGs registered at the kernel crypto API is as
follows:

1. crypto_rng_alloc

2. crypto_rng_reset

3. crypto_rng_generate

If in step 2 you provide NULL as input, the kernel takes get_random_bytes as
seed source. Step 2 is the mandatory.

The Linux-RNG can be fed internally from the hw_random framework by the
function hwrng_fillfn. This function is only used if the current_quality or
default_quality values in the hw_random framework is set.

For the TRNG, it seems to be not set per default, but could be set as either a
boot argument or at runtime via /sys.

If that variable is set and the TRNG is registered, it feeds random data into
the Linux-RNG which in turn is used per default to seed a PRNG. In this case,
no detour via user space is needed to push data from TRNG to the PRNG. Using
that mechanism allows you to benefit from additional entropy the Linux-RNG
collects elsewhere.

quoted

quoted

To me it seems easier to read TRNG (or
/dev/random) and and write the result to PRNG manually (in software).

Indeed this gives more flexibility to the user (choice of engine) but
first, it is slower, and second it reduces the quality of random
numbers (PRNG reseeds itself... but in this model cannot reseed from
TRNG).

Given the reasons above, I would think that keeping the PRMG and TRNG separate
as offered by the current patch seems reasonable. If configured correctly, the
TRNG can seed the PRNG at any time (including boot time) without the need of
user space.

Hi Stephan,

Thanks for explaining the details. This convinces me so I do not have
any objections against current approach of this second RNG driver for
Exynos.

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html