riscv/qemu: QEMU main repository: Please see https://www.qemu.org/docs/master/devel/submitting-a-patch.html for how to submit changes to QEMU. Pull Requests are ignored. Please only use release tarballs from the QEMU website. http://www.qemu.org - qemu

QEMU main repository: Please see https://www.qemu.org/docs/master/devel/submitting-a-patch.html for how to submit changes to QEMU. Pull Requests are ignored. Please only use release tarballs from the QEMU website. http://www.qemu.org

emulation kvm qemu virtualization

History

Jason A. Donenfeld eac7a7791b x86: don't let decompressed kernel image clobber setup_data The setup_data links are appended to the compressed kernel image. Since the kernel image is typically loaded at 0x100000, setup_data lives at `0x100000 + compressed_size`, which does not get relocated during the kernel's boot process. The kernel typically decompresses the image starting at address 0x1000000 (note: there's one more zero there than the compressed image above). This usually is fine for most kernels. However, if the compressed image is actually quite large, then setup_data will live at a `0x100000 + compressed_size` that extends into the decompressed zone at 0x1000000. In other words, if compressed_size is larger than `0x1000000 - 0x100000`, then the decompression step will clobber setup_data, resulting in crashes. Visually, what happens now is that QEMU appends setup_data to the kernel image: kernel image setup_data \|--------------------------\|\|----------------\| 0x100000 0x100000+l1 0x100000+l1+l2 The problem is that this decompresses to 0x1000000 (one more zero). So if l1 is > (0x1000000-0x100000), then this winds up looking like: kernel image setup_data \|--------------------------\|\|----------------\| 0x100000 0x100000+l1 0x100000+l1+l2 d e c o m p r e s s e d k e r n e l \|-------------------------------------------------------------\| 0x1000000 0x1000000+l3 The decompressed kernel seemingly overwriting the compressed kernel image isn't a problem, because that gets relocated to a higher address early on in the boot process, at the end of startup_64. setup_data, however, stays in the same place, since those links are self referential and nothing fixes them up. So the decompressed kernel clobbers it. Fix this by appending setup_data to the cmdline blob rather than the kernel image blob, which remains at a lower address that won't get clobbered. This could have been done by overwriting the initrd blob instead, but that poses big difficulties, such as no longer being able to use memory mapped files for initrd, hurting performance, and, more importantly, the initrd address calculation is hard coded in qboot, and it always grows down rather than up, which means lots of brittle semantics would have to be changed around, incurring more complexity. In contrast, using cmdline is simple and doesn't interfere with anything. The microvm machine has a gross hack where it fiddles with fw_cfg data after the fact. So this hack is updated to account for this appending, by reserving some bytes. Fixup-by: Michael S. Tsirkin <mst@redhat.com> Cc: x86@kernel.org Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Message-Id: <20221230220725.618763-1-Jason@zx2c4.com> Message-ID: <20230128061015-mutt-send-email-mst@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Eric Biggers <ebiggers@google.com> Tested-by: Mathias Krause <minipli@grsecurity.net>		3 years ago
..
chrp_nvram.h	nvram: Exit QEMU if NVRAM cannot contain all -prom-env data	6 years ago
eeprom93xx.h	hw: move headers to include/	13 years ago
fw_cfg.h	x86: don't let decompressed kernel image clobber setup_data	3 years ago
mac_nvram.h	mac_nvram: Use NVRAM_SIZE constant	3 years ago
npcm7xx_otp.h	hw/nvram: NPCM7xx OTP device model	6 years ago
nrf51_nvm.h	Use OBJECT_DECLARE_SIMPLE_TYPE when possible	6 years ago
sun_nvram.h	nvram: Rename openbios_firmware_abi.h into sun_nvram.h	10 years ago
xlnx-bbram.h	hw/nvram: Introduce Xilinx battery-backed ram	5 years ago
xlnx-efuse.h	hw/nvram: Introduce Xilinx eFuse QOM	5 years ago
xlnx-versal-efuse.h	hw/nvram: Introduce Xilinx Versal eFuse device	5 years ago
xlnx-zynqmp-efuse.h	hw/nvram: Introduce Xilinx ZynqMP eFuse device	5 years ago