[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber set
From: |
Mathias Krause |
Subject: |
Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber setup_data |
Date: |
Tue, 10 Jan 2023 13:10:13 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 |
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 <minipli@grsecurity.net>
Thanks,
Mathias
> [snip]
- Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber setup_data, Eric Biggers, 2023/01/05
- Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber setup_data,
Mathias Krause <=
- Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber setup_data, Jason A. Donenfeld, 2023/01/10
- Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber setup_data, Michael S. Tsirkin, 2023/01/10
- Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber setup_data, Eric Biggers, 2023/01/22
- Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber setup_data, Michael S. Tsirkin, 2023/01/23
- Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber setup_data, Jason A. Donenfeld, 2023/01/23
- Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber setup_data, Michael S. Tsirkin, 2023/01/28
- Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber setup_data, Daniel P . Berrangé, 2023/01/30
Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber setup_data, Philippe Mathieu-Daudé, 2023/01/23