On Fri, Apr 22, 2022 at 03:42:46PM +0200, Jason A. Donenfeld wrote: > Hey Guenter, > > On Tue, Mar 22, 2022 at 6:56 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > > > > On 3/22/22 10:09, Jason A. Donenfeld wrote: > > > Hey Guenter, > > > > > > On Tue, Mar 22, 2022 at 08:58:20AM -0700, Guenter Roeck wrote: > > >> On Thu, Feb 17, 2022 at 05:28:48PM +0100, Jason A. Donenfeld wrote: > > >>> This topic has come up countless times, and usually doesn't go anywhere. > > >>> This time I thought I'd bring it up with a slightly narrower focus, > > >>> updated for some developments over the last three years: we finally can > > >>> make /dev/urandom always secure, in light of the fact that our RNG is > > >>> now always seeded. > > >>> > > >> > > >> [ ... ] > > >> > > >> This patch (or a later version of it) made it into mainline and causes a > > >> large number of qemu boot test failures for various architectures (arm, > > >> m68k, microblaze, sparc32, xtensa are the ones I observed). Common > > >> denominator is that boot hangs at "Saving random seed:". A sample bisect > > >> log is attached. Reverting this patch fixes the problem. > > > > > > As Linus said, it was worth a try, but I guess it just didn't work. For > > > my own curiosity, though, do you have a link to those QEMU VMs you could > > > share? I'd sort of like to poke around, and if we do ever reattempt this > > > sometime down the road, it seems like understanding everything about why > > > the previous time failed might be a good idea. > > > > > > > Everything - including the various root file systems - is at > > git@xxxxxxxxxx:groeck/linux-build-test.git. Look into rootfs/ for the > > various boot tests. I'll be happy to provide some qemu command lines > > if needed. > > I've been playing with a few things, and I'm wondering how close I am > to making this problem go away. I just made this branch: > https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/log/?h=jd/for-guenter > > Any interest in setting your tests on that and seeing if it still > breaks? Or, perhaps better, do you have a single script that runs all Looks like your code is already in -next; I see the same failures in your tree and there. openrisc generates a warning backtrace. WARNING: CPU: 0 PID: 0 at drivers/char/random.c:1006 rand_initialize+0x148/0x174 Missing cycle counter and fallback timer; RNG entropy collection will consequently suffer. parisc crashes. [ 0.000000] Kernel Fault: Code=15 (Data TLB miss fault) at addr 00000000 [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc3-32bit+ #1 [ 0.000000] [ 0.000000] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [ 0.000000] PSW: 00000000000001001011111100001110 Not tainted [ 0.000000] r00-03 0004bf0e 10f2c978 10773aa0 10e74300 [ 0.000000] r04-07 00000004 10e74208 10e869d0 10e83978 [ 0.000000] r08-11 f0023b90 f0023390 0004000e 10104f68 [ 0.000000] r12-15 00000002 00000000 00000008 fffffff9 [ 0.000000] r16-19 00000028 00080000 00000000 10dc6364 [ 0.000000] r20-23 10dc6364 00000000 00000000 fefefeff [ 0.000000] r24-27 00000000 00000004 00000000 10dc6178 [ 0.000000] r28-31 0073a08d 80000000 10e74340 00000000 [ 0.000000] sr00-03 00000000 00000000 00000000 00000000 [ 0.000000] sr04-07 00000000 00000000 00000000 00000000 [ 0.000000] [ 0.000000] IASQ: 00000000 00000000 IAOQ: 1024d09c 1024d0a0 [ 0.000000] IIR: 0f401096 ISR: 00000000 IOR: 00000000 [ 0.000000] CPU: 0 CR30: 10e869d0 CR31: 00000000 [ 0.000000] ORIG_R28: 10e83ce8 [ 0.000000] IAOQ[0]: random_get_entropy_fallback+0x18/0x38 [ 0.000000] IAOQ[1]: random_get_entropy_fallback+0x1c/0x38 [ 0.000000] RP(r2): add_device_randomness+0x30/0xc8 [ 0.000000] Backtrace: [ 0.000000] [<10773aa0>] add_device_randomness+0x30/0xc8 [ 0.000000] [<10108734>] collect_boot_cpu_data+0x44/0x270 [ 0.000000] [<10104f28>] setup_arch+0x98/0xd4 [ 0.000000] [<10100a90>] start_kernel+0x8c/0x6d0 s390 crashes silently, no crash log. Hope that helps, Guenter
