On Mon, Jan 30, 2023 at 03:19:59PM -0500, Michael S. Tsirkin wrote: > From: "Jason A. Donenfeld" <ja...@zx2c4.com> > > 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 <m...@redhat.com> > Cc: x...@kernel.org > Cc: Philippe Mathieu-Daudé <phi...@linaro.org> > Cc: H. Peter Anvin <h...@zytor.com> > Cc: Borislav Petkov <b...@alien8.de> > Cc: Eric Biggers <ebigg...@kernel.org> > Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> > Message-Id: <20221230220725.618763-1-ja...@zx2c4.com> > Message-ID: <20230128061015-mutt-send-email-...@kernel.org> > Reviewed-by: Michael S. Tsirkin <m...@redhat.com> > Signed-off-by: Michael S. Tsirkin <m...@redhat.com> > Tested-by: Eric Biggers <ebigg...@google.com> > Tested-by: Mathias Krause <mini...@grsecurity.net>
This one should wind up in the stable point release too. Dunno what the procedure for that is. Jason
