Ok I will resend the pull request. Apologies for overstepping. Paolo
Il ven 22 lug 2022, 16:37 Alex Bennée <alex.ben...@linaro.org> ha scritto: > > "Jason A. Donenfeld" <ja...@zx2c4.com> writes: > > > 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. > > That sounds suspiciously like inventing a new ABI between QEMU and > guests which we generally try to avoid. The DTB exposed to the first > stage may never be made visible to the following stages or more likely a > sanitised version is prepared by the previous stage. Generally QEMU just > tries to get the emulation right so the firmware/software can get on > with it's thing. Indeed the dynamic DTB for -M virt and friends is an > oddity compared to most of the other machine types which assume the user > has a valid DTB. > > Either way given how close to release we are I'd rather drop this patch. > > > 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. > > The original intent of the guest-loader was to make testing of > hypervisors easier because the alternative is getting a multi-stage boot > chain of firmware, boot-loaders and distro specific integration working > which can be quite opaque to debug (c.f. why -kernel/-initrd exist and > not everyone boots via -bios/-pflash). > > > > > Jason > > > -- > Alex Bennée > >
