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-next>] [day] [month] [year] [list]
Date:   Wed, 26 May 2021 11:11:00 +0300
From:   Mike Rapoport <rppt@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Mike Rapoport <rppt@...nel.org>,
        untaintableangel@...mail.co.uk, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH] x86/Kconfig: decrease maximum of X86_RESERVE_LOW to 512K

From: Mike Rapoport <rppt@...ux.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.

Decrease the maximum of X86_RESERVE_LOW range to 512K to allow blocking the
use of most of the low memory by the kernel while still leaving space for
allocations that should be compatible with real mode.

Update the Kconfig help text of X86_RESERVE_LOW to make it explicit that
kernel requires low memory to boot properly.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=213177
Fixes: a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
Signed-off-by: Mike Rapoport <rppt@...ux.ibm.com>
---
 arch/x86/Kconfig | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0045e1b44190..7a972b77819e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1696,7 +1696,7 @@ config X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK
 config X86_RESERVE_LOW
 	int "Amount of low memory, in kilobytes, to reserve for the BIOS"
 	default 64
-	range 4 640
+	range 4 512
 	help
 	  Specify the amount of low memory to reserve for the BIOS.
 
@@ -1711,8 +1711,11 @@ config X86_RESERVE_LOW
 	  You can set this to 4 if you are absolutely sure that you
 	  trust the BIOS to get all its memory reservations and usages
 	  right.  If you know your BIOS have problems beyond the
-	  default 64K area, you can set this to 640 to avoid using the
-	  entire low memory range.
+	  default 64K area, you can set this to 512 to avoid using most
+	  of the low memory range.
+
+	  Note, that a part of the low memory range is still required for
+	  kernel to boot properly.
 
 	  If you have doubts about the BIOS (e.g. suspend/resume does
 	  not work or there's kernel crashes after certain hardware

base-commit: c4681547bcce777daf576925a966ffa824edd09d
-- 
2.28.0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ