Re: [PATCH v4 00/11] rerandomize RNG seeds on reboot and handle record&replay

["Jason A. Donenfeld" <Jason@zx2c4.com>]

On Tue, Oct 25, 2022 at 05:39:27PM +0100, Peter Maydell wrote:
> On Tue, 25 Oct 2022 at 01:43, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > When the system reboots, the rng seed that QEMU passes should be
> > re-randomized, so that the new boot gets a new seed. This series wires
> > that up for FDT.
> >
> > Then, since the record&replay subsystem makes use of reset as well, we
> > add a new reset cause for record&replay, so that we can avoid
> > re-randomizing in these cases.
> >
> > Version 4 prevents the new reset type from leaking over QAPI, documents
> > this alongside which version it was introduced, and adds mips and m68k
> > machine types to the queue.
> >
> > Jason A. Donenfeld (11):
> >   reset: allow registering handlers that aren't called by snapshot
> >     loading
> >   device-tree: add re-randomization helper function
> >   x86: do not re-randomize RNG seed on snapshot load
> >   arm: re-randomize rng-seed on reboot
> >   riscv: re-randomize rng-seed on reboot
> >   m68k/virt: do not re-randomize RNG seed on snapshot load
> >   m68k/q800: do not re-randomize RNG seed on snapshot load
> >   mips/boston: re-randomize rng-seed on reboot
> >   mips/malta: pass RNG seed via env var and re-randomize on reboot
> >   openrisc: re-randomize rng-seed on reboot
> >   rx: re-randomize rng-seed on reboot
> 
> Hi; I've taken all of these except the mips/malta patch into
> target-arm.next. I have some comments on that one but I
> don't see any reason to hold up the rest of these while we
> sort those out.

Too bad. Philippe does not respond to my emails, so no discussion has
been possible. If you or someone more responsive would like to take over
in that discussion, that'd be great. Let's talk.

Jason