On Fri, Oct 04, 2019 at 07:56:01PM +0000, Safford, David (GE Global Research, US) wrote: > > > From: linux-integrity-owner@xxxxxxxxxxxxxxx <linux-integrity- > > owner@xxxxxxxxxxxxxxx> On Behalf Of Jarkko Sakkinen > > Sent: Friday, October 4, 2019 2:27 PM > > Subject: EXT: Re: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes() > > > > If you are able to call tpm_get_random(), the driver has already registered > > TPN as hwrng. With this solution you fail to follow the principle of defense in > > depth. If the TPM random number generator is compromissed (has a bug) > > using the entropy pool will decrease the collateral damage. > > And if the entropy pool has a bug or is misconfigured, you lose everything. > That does not sound like defense in depth to me. In the real world > I am not aware of a single instance of RNG vulnerability on a TPM. > I am directly aware of several published vulnerabilities in embedded systems > due to a badly ported version of the kernel random pool. In addition, > the random generator in a TPM is hardware isolated, and less likely to be > vulnerable to side channel or memory manipulation errors. The TPM > RNG is typically FIPS certified. The use of the TPM RNG was a deliberate > design choice in trusted keys. Hmm... so is RDRAND opcode FIPS certified. Kernel has the random number generator for two reasons: 1. To protect against bugs in hwrng's. 2. To protect against deliberate backdoors in hwrng's. How TPM RNG is guaranteed to protect against both 1 and 2? If I would agree what you say, that'd be argument against using kernel random number generator *anywhere* in the kernel. Even with the entropy issues it is least worst thing to use for key generations for better or worse. /Jarkko
