Re: [PATCH v10 2/3] arm64: random: Add data to pool from setup_arch()
From: Mark Brown <broonie@kernel.org>
Date: 2020-01-15 12:07:14
On Wed, Jan 15, 2020 at 09:16:16AM +0000, Will Deacon wrote:
On Wed, Jan 15, 2020 at 08:48:46AM +0100, Ard Biesheuvel wrote:
quoted
quoted
Note that we are only adding data here, it will be mixed into the pool but won't be credited as entropy. There are currently no suitable interfaces for that at present - extending the random code to provide
quoted
This is slightly unfortunate, as this way, we lose the ability to use random.trust_cpu=1 to get the entropy credited and initialize CRNG early.
Right. OTOH that's a bit of a mess to do, I do have some thoughts but it's a bit of a mess trying to do it tastefully, especially when considering that you probably don't want an interface that it's easy for something to misuse. The effort involved certainly seems large enough to handle separately.
Agreed. Do you think we should wait for that support before merging the series? Given that I don't know of any CPUs implementing this extension, we can probably afford not to rush this in.
It's implemented in at least the fast models already, not checked any of the other emulators, so there's some possibility of people using it while developing other things and hopefully at least some of the various CI systems will be including emulated platforms with newer extensions in their coverage so might gain some benefit from it. Frankly the only reason I'm looking at this at all is that I'd written patch 3 because I was getting fed up with KASLR initialization being easily disabled when I was trying to test E0PD on the models (especially before I added the status print at boot to KASLR so this happened silently), having this in mainline would've helped considerably when working on that. I don't see any downside to having the code in mainline as is, even though it's not ideal it does make things better since if for some reason anyone does end up running this code on a system that has the feature they'll get at least some benefit from it even if nothing else happens. The bulk of the code isn't going to change when the early init stuff gets improved and includes tables like cpufeature.h that make it annoying to hold out of tree, the bits that are going to change can just as well be worked on incrementally as held out of tree entirely and having the rest in means there's less friction doing that.