On Wed, Jan 11, 2023 at 09:44:34AM +0100, Ard Biesheuvel wrote: > On Tue, 10 Jan 2023 at 20:45, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > > > On Tue, Jan 10, 2023 at 6:09 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Tue, Jan 10, 2023 at 05:57:21PM +0100, Jason A. Donenfeld wrote: > > > > Thanks! IIRC, this applies to all current stable kernels (now that > > > > you've sunsetted 4.9). > > > > > > It does not apply cleanly to 5.4.y or 4.19.y or 4.14.y so can you > > > provide working backports for them? > > > > I did 5.4.y, which turned out to be hairy than I wanted. You and Ard > > can decide if you want it or not. I'll leave 4.19 and 4.14 for another > > day. > > I appreciate you spending the effort, but I'm not convinced this is > worth the risk. You are backporting new functionality (invoking the > firmware's RNG protocol at boot on x86), and we might end up > regressing on systems where the firmware's implementation is > problematic, even if the patch by itself is correct. This applies to > mixed mode especially, as the conversion between Win64 and i386 > calling conventions has kicked up some very surprising issues in the > past. Yeah, I'll leave this alone on those old kernel trees. They are primarily only used in Android (i.e. arm64) systems and shouldn't be messing with efi. Those x86 systems still stuck using these old kernels are fragile enough, and should have moved to newer kernels anyway... thanks, greg k-h
