Hey Alex, On Fri, Jul 22, 2022 at 10:45:19AM +0100, Alex Bennée wrote: > 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.
I think that's also my understanding, but let me tell you what I was thinking with regards to rng-seed there, and you can tell me if I'm way off. The guest-loader puts in memory various loaders in a multistage boot. Let's call it stage0, stage1, stage2, and finally the kernel. Normally, rng-seed is only given to one of these stages. That stage may or may not pass it to the next one, and it most probably does not. And why should it? The host is in a better position to generate these seeds, rather than adding finicky and fragile crypto ratcheting code into each stage bootloader. So, instead, QEMU can just give each stage its own seed, for it to do whatever with. This way, if stage1 does nothing, at least there's a fresh unused one available for the kernel when it finally gets there. Does what I describe correspond at all with the use of guest-loader? If so, maybe this patch should stay? If not, discard it as rubbish. Jason
