Messages in this thread |  | | Date | Sat, 31 Dec 2022 19:31:21 -0800 | Subject | Re: [PATCH qemu] x86: don't let decompressed kernel image clobber setup_data | From | "H. Peter Anvin" <> |
| |
On 12/31/22 19:21, H. Peter Anvin wrote: >> >>> Alternatively, setup_data could be relocated, the boot param protocol >>> could be bumped, and then QEMU could conditionalized it's use of >>> setup_data based on that protocol version. That'd work, but seems a bit >>> more involved. >> >> I think this is at least worth considering because the kernel overwriting >> setup_data after having been told where that setup_data is located is >> not really >> nice. >> >> Well not explicitly at least - it gets the pointer to the first >> element and >> something needs to traverse that list to know which addresses are >> live. But >> still, that info is there so perhaps we need to take setup_data into >> consideration too before decompressing... >>
It would probably be a good idea to add a "maximum physical address for initrd/setup_data/cmdline" field to struct kernel_info, though. It appears right now that those fields are being identity-mapped in the decompressor, and that means that if 48-bit addressing is used, physical memory may extend past the addressable range.
-hpa
|  |