Re: [PATCH] hw/arm/virt: dt: add rng-seed property

[Peter Maydell]

On Wed, 29 Jun 2022 at 16:56, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> On Wed, Jun 29, 2022 at 04:24:20PM +0100, Alex Bennée wrote:
> > Given the use case for the dtb-kaslr-seed knob I wonder if we should
> > have a common property and deprecate the kaslr one? As of this patch
> > existing workflows will break until command lines are updated to suppress
> > the second source of randomness.
> >
> > Maybe it would be better to have a single a new property
> > (dtb-rng-seeds?) which suppresses both dtb entries and make
> > dtb-kaslr-seed an alias and mark it as deprecated.
>
> No, I don't think so. If anything, I'll try to get rid of kaslr-seed
> upstream at some point if that makes sense. But until that happens --
> that is, until I have the conversations with people who added these and
> care about their semantics -- assume that there's granularity for some
> good reason. No need to put the cart before the horse.
>
> This is a simple patch doing a simple thing in exactly the way that
> things are already being done. I really don't want to do much more than
> that here. If you want to bikeshed it further, send a follow up patch.

It's adding a command line option, though. Those we have to get
right the first time, because for QEMU they're kind of like ABI
to our users. We *can* clean them up if we find we've made a mistake,
but we have to go through a multi-release deprecation process to do it,
so it's much less effort overall to make sure we have the command line
syntax right to start with.

If there's a good use case for the two seeds to be separately
controllable, that's fine. But I'd rather we find that out for
certain before we put a second control knob and make all our
users with workflows where they want non-random dtb blobs find
out about it and flip it.

thanks
-- PMM