Hi Jason! Am 30.12.22 um 23:07 schrieb Jason A. Donenfeld: > 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.
I just ran into this very issue yesterday when trying to boot a 6.1 kernel. pipacs pointed me to some changes of yours[1] which confirmed, the issue is related to the additional setup_data entries, as adding, e.g., '-M pc-i440fx-7.0' to the QEMU command line made the bug vanish (as QEMU then omits adding the random seed setup_data entries) . [1] https://github.com/qemu/qemu/commit/67f7e426e538 After digging a while I found this thread and it fixes the issue for me, thereby: Tested-by: Mathias Krause <mini...@grsecurity.net> Thanks, Mathias > [snip]