On Tue, Oct 29, 2019 at 07:58:16AM -0700, James Bottomley wrote:
On Tue, 2019-10-29 at 10:42 +0200, Jarkko Sakkinen wrote:
On Mon, Oct 21, 2019 at 02:39:39PM +0300, Jarkko Sakkinen wrote:
On Thu, Oct 17, 2019 at 09:04:40PM +0300, Jarkko Sakkinen wrote:
On Wed, Oct 16, 2019 at 03:10:29PM -0400, James Bottomley wrote:
On Wed, 2019-10-16 at 19:25 +0300, Jarkko Sakkinen wrote:
On Wed, Oct 16, 2019 at 08:34:12AM -0400, James Bottomley wrote: > reversible ciphers are generally frowned upon in random > number > generation, that's why the krng uses chacha20. In general > I think > we shouldn't try to code our own mixing and instead should > get the > krng to do it for us using whatever the algorithm du jour > that the > crypto guys have blessed is. That's why I proposed adding > the TPM > output to the krng as entropy input and then taking the > output of > the krng.
It is already registered as hwrng. What else?
It only contributes entropy once at start of OS.
Ok.
Was the issue that it is only used as seed when the rng is init'd first? I haven't at this point gone to the internals of krng.
Basically it was similar to your xor patch except I got the kernel rng to do the mixing, so it would use the chacha20 cipher at the moment until they decide that's unsafe and change it to something else:
https://lore.kernel.org/linux-crypto/1570227068.17537.4.camel@H ansenPartnership.com/
It uses add_hwgenerator_randomness() to do the mixing. It also has an unmixed source so that read of the TPM hwrng device works as expected.
Thinking that could this potentially racy? I.e. between the calls something else could eat the entropy added?
Also, what is wrong just taking one value from krng and mixing it with a value from TPM RNG where needed? That would be non-racy too.
I guess we can move forward with this?
Sure I suppose; can we can figure out how to get the mixing function du jour exposed?
Maybe it is best to reflect the whole issue in the context of the Sumit's 2nd patch set, which adds ARM TEE support in order to move forward.
/Jarkko