linux-kernel - Re: [PATCH] x86/Kconfig: decrease maximum of X86_RESERVE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 26 May 2021 20:14:44 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Mike Rapoport <rppt@...nel.org>
Cc:     Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        untaintableangel@...mail.co.uk, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/Kconfig: decrease maximum of X86_RESERVE_LOW to 512K

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?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette