linux-kernel - Re: [PATCH] tpm: Add module parameter for hwrng quality.

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] [day] [month] [year] [list]

Date:   Tue, 17 Jul 2018 22:43:12 -0400
From:   "David R. Bild" <david.bild@...tum.com>
To:     Louis Collard <louiscollard@...omium.org>
Cc:     linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tpm: Add module parameter for hwrng quality.

On Wed, Jul 4, 2018 at 2:54 AM, Louis Collard <louiscollard@...omium.org> wrote:
> On Fri, Jun 29, 2018 at 9:03 PM, David R. Bild <david.bild@...tum.com> wrote:
>> As a point of clarification (and correct me if I'm wrong), the TPM is
>> always ready used to seed the rng. It just doesn't update the entropy
>> pool estimate.
>
> Good point.
>
>>
>> So, perhaps the default value for the TPM hwrng quality should be
>> non-zero (in addition to the module param that lets users override
>> it)?
>
> That makes sense to me, however I can imagine that some users would
> prefer to not have the TPM enabled as an ongoing source of entropy by
> default.

Fair enough.

> Following on from your previous point - perhaps we can just make a
> small change to how the initial seeding is done: maybe we can replace
> the call to crng_slow_load (via add_early_randomness and
> add_device_randomness) with a call (indirectly) to crng_fast_load. (We
> might also need to increase the amount of data read at this point.)
>
> This would update crng_init_cnt and crng_init, and calls to getrandom
> [without GRND_RANDOM] would not block.

Interesting.

add_hwgenereator_randomness() will call crng_fast_load(), regardless
of entropy estimate/quality, if crng_init is 0.  So initializing
crng_init from the hwrng, regardless of quality, is already the
intent.

But hw_random only calls add_hwgenerator_randomness() if
current_quality > 0, via the hwrng_fillfn() kthread.

All that to say, I agree.  add_early_randomness() should (indirectly)
call crng_fast_load(), like add_hwgenerator_randomness() does.

> This obviously doesn't solve the issue if there are blocking calls on
> boot that are querying random rather than urandom; I don't believe
> that would be a problem for our use case though.
>

It wouldn't be a problem for our use case either.

Best,
David