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: > > 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 > > > 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
