Re: [PATCH] hw/i386: pass RNG seed to e820 setup table

[Daniel P . Berrangé]

On Fri, Jul 08, 2022 at 02:04:40PM +0200, Jason A. Donenfeld wrote:
> Hi Daniel,
> 
> On Fri, Jul 8, 2022 at 2:00 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Thu, Jun 30, 2022 at 01:37:17PM +0200, Jason A. Donenfeld wrote:
> > > Tiny machines optimized for fast boot time generally don't use EFI,
> > > which means a random seed has to be supplied some other way, in this
> > > case by the e820 setup table, which supplies a place for one. This
> > > commit adds passing this random seed via the table. It is confirmed to
> > > be working with the Linux patch in the link.
> >
> > IIUC, this approach will only expose the random seed when QEMU
> > is booted using -kernel + -initrd args.
> >
> > I agree with what you say about most VMs not using UEFI right now.
> > I'd say the majority of general purpose VMs are using SeaBIOS
> > still. The usage of -kernel + -initrd, is typically for more
> > specialized use cases.
> 
> Highly disagree, based on seeing a lot of real world deployment.

I guess we're looking at different places then, as all of the large
scale virt mgmt apps I've experianced with KVM (OpenStack, oVirt,
KubeVirt), along with the small scale ones (GNOME Boxes, virt-manager,
virt-install, Cockpit), etc all primarily use SeaBIOS, and in more
recently times a bit of UEFI.  Direct kernel/initrd boot is usualy
reserved for special cases, since users like to be able to manage
their kernel/initrd inside the guest image.

> Furthermore, this is going to be used within Linux itself for kexec,
> so it makes sense to use it here too.

Ok, useful info.

> > Can we get an approach that exposes a random seed regardless of
> > whether using -kernel, or seabios, or uefi, or $whatever firmware ?
> 
> No.
> 
> > Perhaps (ab)use 'fw_cfg', which is exposed for any x86 VM no matter
> > what config it has for booting ?
> 
> That approach is super messy and doesn't work. I've already gone down
> that route.

What's the problem with it ? fw_cfg is a pretty straightforward
mechanism for injecting data into the guest OS, that we already
use for alot of stuff.

> The entire point here is to include the seed on this part of the boot
> protocol. There might be other opportunities for doing it elsewhere.
> For example, EFI already has a thing.
> 
> Please don't sink a good idea because it doesn't handle every possible
> use case. That type of mentality is just going to result in nothing
> ever getting done anywhere, making a decades old problem last for
> another decade. This patch here is simple and makes a tangible
> incremental advance toward something good, and fits the pattern of how
> it's done on all other platforms.

I'm not trying to sink an idea. If this turns out to be the best
idea, I've no problem with that.

I merely asked some reasonable questions about whether there were
alternative approaches that could solve more broadly useful scenarios,
given the narrow usage of direct kernel boot, in context of the common
VM deployments I've seen at large scale. You can't expect reviewers to
blindly accept any proposal without considering it broader context.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|