All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org
Subject: Re: [PATCH] hw/arm/virt: dt: add rng-seed property
Date: Wed, 29 Jun 2022 17:55:59 +0200	[thread overview]
Message-ID: <Yrx2D/uPxM8YPCYK@zx2c4.com> (raw)
In-Reply-To: <87r137h49s.fsf@linaro.org>

Hi Alex,

On Wed, Jun 29, 2022 at 04:24:20PM +0100, Alex Bennée wrote:
> > The code is exactly the same for kaslr-seed and rng-seed. Everytime
> > there's some kaslr-seed thing, there is now the same rng-seed thing.
> 
> The duplication is annoying but specs are specs - where is this written
> by the way?

The same place as all the ordinary specs:
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/chosen.yaml

> 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.

Jason


  reply	other threads:[~2022-06-29 15:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27 16:07 [PATCH] hw/arm/virt: dt: add rng-seed property Jason A. Donenfeld
2022-06-27 16:12 ` Peter Maydell
2022-06-27 16:36   ` Jason A. Donenfeld
2022-06-28 18:45     ` Jason A. Donenfeld
2022-06-29  9:37       ` Peter Maydell
2022-06-29 10:15         ` Alex Bennée
2022-06-29 10:18         ` Alex Bennée
2022-06-29 11:26           ` Jason A. Donenfeld
2022-06-29 15:24             ` Alex Bennée
2022-06-29 15:55               ` Jason A. Donenfeld [this message]
2022-06-30  9:15                 ` Peter Maydell
2022-06-30 10:22                   ` Jason A. Donenfeld
2022-06-30 10:37                     ` [PATCH v2] " Jason A. Donenfeld
2022-07-04 14:42                       ` Peter Maydell
2022-07-05  0:45                         ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yrx2D/uPxM8YPCYK@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=alex.bennee@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.