|
From: | H. Peter Anvin |
Subject: | Re: [PATCH qemu] x86: don't let decompressed kernel image clobber setup_data |
Date: | Sat, 31 Dec 2022 20:33:59 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 |
On 12/31/22 10:22, Jason A. Donenfeld wrote:
On Sat, Dec 31, 2022 at 03:24:32PM +0100, Borislav Petkov wrote:On Sat, Dec 31, 2022 at 02:51:28PM +0100, Jason A. Donenfeld wrote:That failure is unrelated to the ident mapping issue Peter and I discussed. The original failure is described in the commit message: decompression clobbers the data, so sd->next points to garbage.RightSo with that understanding confirmed, I'm confused at your surprise that hpa's unrelated fix to the different issue didn't fix this issue.
If decompression does clobber the data, then we *also* need to figure out why that is. There are basically three possibilities:
1. If physical KASLR is NOT used: a. The boot loader doesn't honor the kernel safe area properly; b. Somewhere in the process a bug in the calculation of the kernel safe area has crept in. 2. If physical KASLR IS used: The decompressor doesn't correctly keep track of nor relocate all the keep-out zones before picking a target address.One is a bootloader bug, two is a kernel bug. My guess is (2) is the culprit, but (1b) should be checked, too.
-hpa
[Prev in Thread] | Current Thread | [Next in Thread] |