Re: random.c backports for 5.18, 5.17, 5.15, and prior

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, May 23, 2022 at 03:36:02PM +0200, Greg KH wrote:
> On Mon, May 23, 2022 at 02:54:45PM +0200, Jason A. Donenfeld wrote:
> > Hi Greg, Sasha,
> > 
> > I think we're finally at a good point to begin backporting the work I've
> > done on random.c during the last 6 months. I've been maintaining
> > branches for this incrementally as code has been merged into mainline,
> > in order to make this moment easier than otherwise.
> > 
> > Assuming that Linus merges my PR for 5.19 [1] today, all of these
> > patches are (or will be in a few hours) in Linus' tree. I've tried to
> > backport most of the general scaffolding and design of the current state
> > of random.c, while not backporting any new features or unusual
> > functionality changes that might invite trouble. So, for example, the
> > backports switch to using a cryptographic hash function, but they don't
> > have changes like warning when the cycle counter is zero, attempting to
> > use jitter on early uses of /dev/urandom, reseeding on suspend/hibernate
> > notifications, or the vmgenid driver. Hopefully that strikes an okay
> > balance between getting the core backported so that fixes are
> > backportable, but not going too far by backporting new "nice to have"
> > but unessential features.
> > 
> > In this git repo [2], there are three branches: linux-5.15.y,
> > linux-5.17.y, and linux-5.18.y, which contain backports for everything
> > up to and including [1].
> > 
> > You'll probably want to backport this to earlier kernels as well. Given
> > that there hasn't been overly much work on the rng in the last few
> > years, it shouldn't be too hard to take my 5.15.y branch and fill in the
> > missing pieces there to bring it back. Given how much changes, you could
> > probably just take every random.c change for backporting to before 5.15.
> > 
> > There is one snag, which is that some of the work I did during the 5.17
> > cycle depends on crypto I added for WireGuard, which landed in 5.6. So
> > for 5.4 and prior, that will need backports. Fortunately, I've already
> > done this in [3], in the branch backport-5.4.y, which I've kept up to
> > date for a few years now. This occasion might mark the perfect excuse
> > we've been waiting for to just backport WireGuard too to 5.4 (which
> > might make the Android work a bit easier also) :-D.
> > 
> > Let me know if you have any questions, and feel free to poke me on IRC.
> > And if all of the above sounds terrible to you, and you'd rather just
> > not take any of this into stable, I guess that's a valid path to take
> > too.
> 
> Let me look at this later this week after we get this next round of
> stable kernels out.  It's normally a nice calm period for the stable
> kernels so this might not be that bad.

I get build errors in the 5.15 and 5.10 trees when applying these
patches.

Here's the 5.10 error:
In file included from ../crypto/testmgr.c:32:
../include/crypto/drbg.h:139:38: error: field 'random_ready' has incomplete type
  139 |         struct random_ready_callback random_ready;
      |                                      ^~~~~~~~~~~~


And the same error in 5.15.

So obviously I can't take them, I'm doing a simple 'make allmodconfig'
build for these trees on x86-64.

For 5.18 and 5.17, wow, lots of patches, but sure, let's see what
happens, I've queued them up now.

thanks,

greg k-h