Re: [PULL 7/9] hw/guest-loader: pass random seed to fdt

[Alex Bennée]

"Jason A. Donenfeld" <Jason@zx2c4.com> writes:

> Hi Alex,
>
> On Thu, Jul 21, 2022 at 08:36:10PM +0100, Alex Bennée wrote:
>> 
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>> 
<snip>
>> >      uint64_t reg_attr[2] = {cpu_to_be64(s->addr), cpu_to_be64(size)};
>> > +    uint8_t rng_seed[32];
>> >  
>> >      if (!fdt) {
>> >          error_setg(errp, "Cannot modify FDT fields if the machine has 
>> > none");
>> > @@ -55,6 +57,9 @@ static void loader_insert_platform_data(GuestLoaderState 
>> > *s, int size,
>> >      qemu_fdt_add_subnode(fdt, node);
>> >      qemu_fdt_setprop(fdt, node, "reg", &reg_attr, sizeof(reg_attr));
>> >  
>> > +    qemu_guest_getrandom_nofail(rng_seed, sizeof(rng_seed));
>> > +    qemu_fdt_setprop(fdt, node, "rng-seed", rng_seed, sizeof(rng_seed));
>> > +
>> 
>> Why are we inserting this here? The guest-loader is only building on
>> what the machine type has already constructed which in the case of -M
>> virt for riscv and ARM already has code for this.
>
> Wish you would have replied to the list patch before Paolo queued it.

I'm sorry if I didn't get to it in the *checks notes* 2 days since it
was posted. I've been on holiday.

> I don't know this mechanism well but I assumed it would pass a unique
> seed to each chained loader. Let me know if I'm misunderstanding the
> purpose; I have no qualms about dropping this patch.

All the guest-loader does is add the information about where in memory a
guest and/or it's initrd have been placed in memory to the DTB. It's
entirely up to the initial booted code (usually a hypervisor in this
case) to decide what gets passed up the chain to any subsequent guests.

-- 
Alex Bennée