Re: [PATCH 2/2] m68k: virt: generate new RNG seed on reboot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Laurent,

On Fri, Sep 23, 2022 at 3:10 PM Laurent Vivier <laurent@xxxxxxxxx> wrote:

Le 23/09/2022 à 14:50, Geert Uytterhoeven a écrit :
Hi Jason,

On Fri, Sep 23, 2022 at 2:26 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
On Fri, Sep 23, 2022 at 2:23 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
+       if (rng_seed_record && rng_seed_record->size > sizeof(*rng_seed_record) + 2) {
+               u16 len = rng_seed_record->size - sizeof(*rng_seed_record) - 2;
+               get_random_bytes((u8 *)rng_seed_record->data + 2, len);
+               *(u16 *)rng_seed_record->data = len;

Storing the length should use the proper cpu_to_be16 accessor.

Okay, I'll do that for v2.

(Simply out of curiosity, why? Isn't m68k always big endian and this
is arch/ code?)

Yes it is.  But virt_parse_bootinfo() below already uses the right
accessor.

BTW, I guess people thought the same about PowerPC?
Although I agree the probability of someone creating a little-endian
m68k clone in an FPGA or SkyWater project and trying to run Linux on
it quite low ;-)

The way I tested this is by having my initramfs just call
`reboot(RB_AUTOBOOT);`, and having add_bootloader_randomness() print
its contents to the console. I checked that it was both present and
different every time.

Are you sure the new kernel did receive the same randomness as prepared
by get_random_bytes()? I would expect it to just reboot into qemu,
reload the kernel from disk, and recreate a new bootinfo from scratch,
including generating a new random seed.

Yes I'm sure. Without this patch, the new kernel sees the zeroed state.

That's interesting.  So QEMU preserves the old bootinfo, which is
AFAIK not guaranteed to be still available (that's why I added
save_bootinfo()).  Perhaps that works because only memory starting
from a rounded-up value of _end will be used, and you're just lucky?
I'm wondering what else it preserves. It sure has to reload the
kernel image, as at least the data section will no longer contain the
initialization values after a reboot...

Laurent?


In QEMU the loader makes a copy of the kernel and the initrd and this copy is restored on a reset.

I don't think there is a mechanism in QEMU to save the BOOTINFO section, so I think it works by
luck. I will check.

Thanks,
Laurent

Are you sure about that? Or at least, could you point me to where you
think this happens? I'm not as familiar as you with this code base,
but I really am not seeing it. So far as I can tell, on reset, the pc
and stack are reset to their initial places, after TCG resets the cpu
registers to a known state. But the kernel is not reloaded. The same
thing that was in memory before is used again.

Jason




[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux