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

[H. Peter Anvin]

On 5/26/21 11:14 AM, Borislav Petkov wrote:
> On Wed, May 26, 2021 at 07:30:09PM +0300, Mike Rapoport wrote:
>> 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.
> 
> Sure but how are we going to tell the user that if we don't sneak that
> allocation, we won't boot at all. I believe user would kinda like the
> box to boot still, no? :-)
> 
> Yeah, you have that now:
> 
> +         Note, that a part of the low memory range is still required for
> +         kernel to boot properly.
> 
> but then why is 512 ok? And why was 640K the upper limit?
> 
> Looking at:
> 
> d0cd7425fab7 ("x86, bios: By default, reserve the low 64K for all BIOSes")
> 
> and reading that bugzilla
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=16661
> 
> it sounds like it is the amount of memory where BIOS could put crap in.
> 
> Long story short, we reserve the first 64K by default so if someone
> reserves the total range of 640K the early code could probably say
> something like
> 
> "adjusting upper reserve limit to X for the real-time trampoline"
> 
> when the upper limit is too high so that a trampoline can't fit...
> 
> Which is basically what your solution does...
> 
> But then the previous behavior used to work everywhere so if it is only
> cheating, I don't mind doing that as long as boxes keep on booting.
> 
> Or am I missing an aspect?
> 

BIOSes have been known to clobber more than 64K. They aren't supposed to
clobber any.

640K is the limit because that is the address of the EGA/VGA frame
buffer. In the words of Bill Gates "640K ought to be enough for anyone."

	-hpa