On Wed, 29 Jun 2022 at 16:56, Jason A. Donenfeld <ja...@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
