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.

This is all now merged into 5.10 and newer.

For 5.4 I just don't think it's worth the trouble.  Devices based on
that old kernel aren't going to want to deal with the churn like this,
and being forced to add the WG code to it also seems like a lot of
unnecessary work for everyone (including yourself.)

But, I do know that a lot of Android devices are still relying on 5.4,
they already have WG in their kernels so overall this might be a smaller
diff for them?

I don't really know, do you have any people/companies/devices using 5.4
that would want this all added that you can show it is worth it for?

thanks,

greg k-h