Peter Maydell <peter.mayd...@linaro.org> writes:
> On Tue, 28 Jun 2022 at 19:45, Jason A. Donenfeld <ja...@zx2c4.com> wrote:
>>
>> On 6/27/22, Jason A. Donenfeld <ja...@zx2c4.com> wrote:
>> > On 6/27/22, Peter Maydell <peter.mayd...@linaro.org> wrote:
>> >> On Mon, 27 Jun 2022 at 17:07, Jason A. Donenfeld <ja...@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
