Re: [PATCH] x86/Kconfig: decrease maximum of X86_RESERVE_LOW to 512K

[Mike Rapoport <rppt@kernel.org>]

On Wed, May 26, 2021 at 10:47:21AM +0200, Borislav Petkov wrote:
> On Wed, May 26, 2021 at 11:11:00AM +0300, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> > 
> > After the consolidation of early memory reservations introduced by the
> > commit a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
> > the kernel fails to boot if X86_RESERVE_LOW is set to 640K.
> > 
> > The boot fails because real-time trampoline must be allocated under 1M (or
> > essentially under 640K) but with X86_RESERVE_LOW set to 640K the memory is
> > already reserved by the time reserve_real_mode() is called.
> > 
> > Before the reordering of the early memory reservations it was possible to
> > allocate from low memory even despite user's request to avoid using that
> > memory. This lack of consistency could potentially lead to memory
> > corruptions by BIOS in the areas allocated by kernel.
> 
> Hmm, so this sounds weird to me: real-time trampoline clearly has
> precedence over X86_RESERVE_LOW because you need former to boot the
> machine, right?
> 
> In that case, real-time trampoline should allocate first and *then* the
> rest of low range requested to be reserved should be reserved, no?
 
We can restore that behaviour, but it feels like cheating to me. We let
user say "Hey, don't touch low memory at all", even though we know we must
use at least some of it. And then we sneak in an allocation under 640K
despite user's request not to use it.

-- 
Sincerely yours,
Mike.