Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 28 Dec 2022 15:58:12 -0800
From:   "H. Peter Anvin" <hpa@zytor.com>
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
CC:     pbonzini@redhat.com, ebiggers@kernel.org, x86@kernel.org,
        linux-kernel@vger.kernel.org, qemu-devel@nongnu.org,
        ardb@kernel.org, kraxel@redhat.com, bp@alien8.de, philmd@linaro.org
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_qemu=5D_x86=3A_don=27t_let_decomp?= =?US-ASCII?Q?ressed_kernel_image_clobber_setup=5Fdata?=
User-Agent: K-9 Mail for Android
In-Reply-To: <Y6x1knb8udpSyMSp@zx2c4.com>
References: <20221228143831.396245-1-Jason@zx2c4.com> <6cab26b5-06ae-468d-ac79-ecdecb86ef07@linaro.org> <Y6xvJheSYC83voCZ@zx2c4.com> <Y6x1knb8udpSyMSp@zx2c4.com>
Message-ID: <9188EEE9-2759-4389-B39E-0FEBBA3FA57D@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On December 28, 2022 8:57:54 AM PST, "Jason A=2E Donenfeld" <Jason@zx2c4=2E=
com> wrote:
>HELLO H=2E PETER ANVIN,
>E
>L
>L
>O
>
>On Wed, Dec 28, 2022 at 05:30:30PM +0100, Jason A=2E Donenfeld wrote:
>> > Fix looks good, glad you figured out the problem=2E
>>=20
>> I mean, kind of=2E The solution here sucks, especially given that in th=
e
>> worst case, setup_data just gets dropped=2E I'm half inclined to consid=
er
>> this a kernel bug instead, and add some code to relocate setup_data
>> prior to decompression, and then fix up all the links=2E It seems like
>> this would be a lot more robust=2E
>>=20
>> I just wish the people who wrote this stuff would chime in=2E I've had
>> x86@kernel=2Eorg CC'd but so far, no input from them=2E
>
>Apparently you are the x86 boot guru=2E What do you want to happen here?
>Your input would be very instrumental=2E
>
>Jason

Hi!

Glad you asked=2E

So the kernel load addresses are parameterized in the kernel image setup h=
eader=2E One of the things that are so parameterized are the size and possi=
ble realignment of the kernel image in memory=2E

I'm very confused where you are getting the 64 MB number from=2E There sho=
uld not be any such limitation=2E

In general, setup_data should be able to go anywhere the initrd can go, an=
d so is subject to the same address cap (896 MB for old kernels, 4 GB on ne=
wer ones; this address too is enumerated in the header=2E)

If you want to put setup_data above 4 GB, it *should* be ok if and only if=
 the kernel supports loading the initrd high, too (again, enumerated in the=
 header=2E

TL;DR: put setup_data where you put the initrd (before or after doesn't ma=
tter=2E)

To be maximally conservative, link the setup_data list in order from lowes=
t to highest address; currently there is no such item of relevance, but in =
the future there may be setup_data items needed by the BIOS part of the boo=
tstrap in which case they would have to be < 1 MB and precede any items > 1=
 MB for obvious reasons=2E That being said, with BIOS dying it is not all t=
hat likely that such entries will ever be needed=2E