|
From: | H. Peter Anvin |
Subject: | Re: [PATCH qemu] x86: don't let decompressed kernel image clobber setup_data |
Date: | Sat, 31 Dec 2022 19:31:21 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 |
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 overwritingsetup_data after having been told where that setup_data is located is not reallynice.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. Butstill, 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
[Prev in Thread] | Current Thread | [Next in Thread] |