[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y68Js5b0jW/2nLU4@zx2c4.com>
Date: Fri, 30 Dec 2022 16:54:27 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Borislav Petkov <bp@...en8.de>
Cc: "H. Peter Anvin" <hpa@...or.com>, pbonzini@...hat.com,
ebiggers@...nel.org, x86@...nel.org, linux-kernel@...r.kernel.org,
qemu-devel@...gnu.org, ardb@...nel.org, kraxel@...hat.com,
philmd@...aro.org
Subject: Re: [PATCH qemu] x86: don't let decompressed kernel image clobber
setup_data
On Thu, Dec 29, 2022 at 01:47:49PM +0100, Borislav Petkov wrote:
> On Wed, Dec 28, 2022 at 11:31:34PM -0800, H. Peter Anvin wrote:
> > As far as a crash... that sounds like a big and a pretty serious one at that.
> >
> > Could you let me know what kernel you are using and how *exactly* you are booting it?
>
> Right, with CONFIG_X86_VERBOSE_BOOTUP=y in a guest here, it says:
>
> early console in extract_kernel
> input_data: 0x000000000be073a8
> input_len: 0x00000000008cfc43
> output: 0x0000000001000000
> output_len: 0x000000000b600a98
> kernel_total_size: 0x000000000ac26000
> needed_size: 0x000000000b800000
> trampoline_32bit: 0x000000000009d000
>
> so that's a ~9M kernel which gets decompressed at 0x1000000 and the
> output len is, what, ~180M which looks like plenty to me...
I think you might have misunderstood the thread. First, to reproduce the
bug that this patch fixes, you need a kernel with a compressed size of
around 16 megs, not 9. Secondly, that crash is well understood and
doesn't need to be reproduced; this patch fixes it. Rather, the question
now is how to improve this patch to remove the 62 meg limit. I'll follow
up with hpa's request for reproduction info.
Jason
Powered by blists - more mailing lists