On Fri, Aug 05, 2022 at 07:29:29PM +0200, Paolo Bonzini wrote: > 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 So IIUC you retract your pc: add property for Linux setup_data random number seed then? It's neither of the two options above. -- MST
