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

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Tue, 28 Jun 2022 at 19:45, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>>
>> On 6/27/22, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>> > On 6/27/22, Peter Maydell <peter.maydell@linaro.org> wrote:
>> >> On Mon, 27 Jun 2022 at 17:07, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>> >>>
>> >>> In 60592cfed2 ("hw/arm/virt: dt: add kaslr-seed property"), the
>> >>> kaslr-seed property was added, but the equally as important rng-seed
>> >>> property was forgotten about, which has identical semantics for a
>> >>> similar purpose. This commit implements it in exactly the same way as
>> >>> kaslr-seed.
>> >>
>> >> Not an objection, since if this is what the dtb spec says we need
>> >> to provide then I guess we need to provide it, but:
>> >> Why do we need to give the kernel two separate random seeds?
>> >> Isn't one sufficient for the kernel to seed its RNG and generate
>> >> whatever randomness it needs for whatever purposes it wants it?
>> >>
>> >
>> > Seems a bit silly to me too. `rng-seed` alone ought to be sufficient.
>> > After the kernel calls add_bootloader_randomness() on it,
>> > get_random_long() can be used for kaslr'ing and everything else too.
>> > So I'm not sure what's up, but here we are. Maybe down the line I'll
>> > look into the details and formulate a plan to remove `kaslr-seed` if
>> > my supposition is correct.
>> >
>> > Jason
>> >
>>
>> Was wondering if you planned to queue this up?
>
> It's on my todo list to review...

Erm isn't this replicating kaslr-seed?

  static void create_kaslr_seed(MachineState *ms, const char *node)
  {
      uint64_t seed;

      if (qemu_guest_getrandom(&seed, sizeof(seed), NULL)) {
          return;
      }
      qemu_fdt_setprop_u64(ms->fdt, node, "kaslr-seed", seed);
  }


which BTW we provide a knob (dtb-kaslr-seed) to suppress because it can
get in the way of secure instrumentation/checksums done by secure boot.

>
> -- PMM


-- 
Alex Bennée