On Tue, Oct 24, 2017 at 11:37:57AM -0600, Jason Gunthorpe wrote:

On Tue, Oct 24, 2017 at 10:02:00AM -0700, Dmitry Torokhov wrote:

quoted

tpm-rng is abomination that should be kicked out as soon as possible.
It wrecks havoc with the power management (TPM chip drivers may go
into suspend state, but tpm_rng does not do any power management and
happily forwards requests to suspended hardware) and may be available
when there is no TPM at all yet (the drivers have not been probed yet,
or have gotten a deferral, etc).

Makes sense

quoted

TPM core should register HWRNGs when chips are ready.

The main thing I've wanted from the TPM RNG is
'add_early_randomness'..

I see... However you can't add any randomness if hardware is not quite
there yet.

We can certainly provide a TPM interface to hwrng, it seems
reasonable.

Excep that we already have a user api in /dev/tpm to access the
tpm RNG, is the duplication a problem?

If we already have userspace API we have to maintain this, even if it is
duplicate, there is no way around it. I'd expect most of the users will
use unified random API, while some TPM-oriented users may still go via
/dev/tpm to use the same API as all other their requests.

Thanks.

-- 
Dmitry

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot