On 8/5/22 13:08, Ard Biesheuvel wrote:
Does it work to place setup_data at the end of the cmdline file instead
of having it at the end of the kernel file? This way the first item
will be at 0x20000 + cmdline_size.
Does QEMU always allocate the command line statically like that?
AFAIK, OVMF never accesses that memory to read the command line, it
uses fw_cfg to copy it into a buffer it allocates itself. And I guess
that implies that this region could be clobbered by OVMF unless it is
told to preserve it.
No it's not. :( It also goes to gBS->AllocatePages in the end.
At this point it seems to me that without extra changes the whole
setup_data concept is dead on arrival for OVMF. In principle there's no
reason why the individual setup_data items couldn't include interior
pointers, meaning that the setup_data _has_ to be at the address
provided in fw_cfg by QEMU.
One way to "fix" it would be for OVMF to overwrite the pointer to the
head of the list, so that the kernel ignores the setup data provided by
QEMU. Another way would be to put it in the command line fw_cfg blob and
teach OVMF to use a fixed address for the command line. Both are ugly,
and both are also broken for new QEMU / old OVMF.
In any case, I don't think this should be fixed so close to the release.
We have two possibilities:
1) if we believe "build setup_data in QEMU" is a feasible design that
only needs more yak shaving, we can keep the code in, but disabled by
default, and sort it out in 7.2.
2) if we go for an alternative design, it needs to be reverted. For
example the randomness could be in _another_ fw_cfg file, and the
linuxboot DMA can patch it in the setup_data.
With (2) the OVMF breakage would be limited to -dtb, which more or less
nobody cares about, and we can just look the other way.
Paolo
