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. thanks, greg k-h
