On Thu, Aug 18, 2022 at 05:38:37PM +0200, Jason A. Donenfeld wrote:
> Hey Gerd,
>
> > Joining the party late (and still catching up the thread). Given we
> > don't need that anyway with EFI, only with legacy BIOS: Can't that just
> > be a protocol between qemu and pc-bios/optionrom/*boot*.S on how to pass
> > those 48 bytes random seed?
>
> Actually, I want this to work with EFI, very much so.
With EFI the kernel stub gets some random seed via EFI_RNG_PROTOCOL.
I can't see any good reason to derive from that. It works no matter
how the kernel gets loaded.
OVMF ships with a driver for the virtio-rng device. So just add that
to your virtual machine and seeding works fine ...
> If our objective was to just not break EFI, the solution would be
> simple: in the kernel we can have EFISTUB ignore the setup_data field
> from the image, and then bump the boot header protocol number. If QEMU
> sees the boot protocol number is below this one, then it won't set
> setup_data. Done, fixed.
As mentioned elsewhere in the thread patching in physical addresses on
qemu side isn't going to fly due to the different load methods we have.
> Your option ROM idea is interesting; somebody mentioned that elsewhere
> too I think.
Doing the setup_data patching in the option rom has the advantage that
it'll only happen with that specific load method being used. Also the
option rom knows where it places stuff in memory so it is in a much
better position to find a good & non-conflicting place for the random
seed. Also reserve/allocate memory if needed etc.
> I'm wondering, though: do option ROMs still run when
> EFI/OVMF is being used?
No, they are not used with EFI. OVMF has a completely independent
implementation for direct kernel boot.
The options I see for EFI are:
(1) Do nothing and continue to depend on virtio-rng.
(2) Implement an efi driver which gets those 48 seed bytes from
qemu by whatever means we'll define and hands them out via
EFI_RNG_PROTOCOL.
take care,
Gerd
