On 7/20/22 15:03, Jason A. Donenfeld wrote:
Hi Paolo,
On Tue, Jul 19, 2022 at 01:53:00PM +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. For this
purpose, Linux (≥5.20) supports passing a seed in the setup_data table
with SETUP_RNG_SEED, specially intended for hypervisors, kexec, and
specialized bootloaders. The linked commit shows the upstream kernel
implementation.
Having received your message in the other thread hinting, "I think
there are some issues with migration compatibility of setup_data and
they snowball a bit, so I'll reply there," and being a bit eager to get
this moving, I thought I'd preempt that discussion by trying to guess
what you have in mind and replying to it. Speculative email execution...
The SETUP_RNG_SEED parameter is used only during boot, and Linux takes
pains to zero out its content after using. If a VM is migrated or
copied, the RNG state is also migrated, just as is the case before
SETUP_RNG_SEED. For that reason, Linux also has a "vmgenid" driver,
which QEMU supports via `-device vmgenid,guid=auto`, which is an ACPI
mechanism for telling the RNG to reseed under various migration
circumstances. But this is merely complementary to SETUP_RNG_SEED, which
is intended as a very simple mechanism for passing a seed at the
earliest moment in boot, akin to DT's "rng-seed" node.
Hopefully this answers what I think you were going to ask, and sorry if
it's a total non-sequitur.
It's not entirely what I was thinking about but it is interesting anyway
so thanks for writing that. Sorry it took some time to reply but these
live migration issues are subtle and I wanted to be sure of what is and
isn't a problem.
The issue with live migration is that the setup data changes from before
to after the patches. This means that a live migration exactly _in the
middle_ of reading the Linux boot data could fail badly. For example,
you could migrate in the middle of reading the DTB, and it would be
shifted by the ~50 bytes of the setup_data and seed. The size would
also not match so, even though probably things would mostly work if you
place the seed last, that's not really optimal either.
Now I understand that this would be exceedingly unlikely or downright
impossible, but the main issue is that, roughly speaking, we try to
guarantee unchanged guest ABI on every execution with the appropriate
command line options. So the solution is to add a machine property
(e.g. "-M linuxboot-seed=...") that allows enabling/disabling it, and
then making it default to off with machine types like pc-i440fx-7.0 that
never had the seed.
In turn this means that the "shape" of the linked list changes a bit and
it's better to abstract the creation of the setup_data struct in a
separate function. And then you've got to move the various local
variables of x86_load_linux into a struct for sharing. As I said, it
snowballs a bit, but I should be sending out patches later today.
As an aside, QEMU tends to only include code after Linux supports it,
but it's in your rng tree so the timing is right; I'll queue the FDT
ones for 7.1 since it's nice to have feature parity across all FDT boards.
Paolo
