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>] [day] [month] [year] [list]
Message-Id: <20250405-fix-e820-nosave-v2-1-d40dbe457c95@qtmlabs.xyz>
Date: Sat, 05 Apr 2025 17:18:24 +0700
From: Myrrh Periwinkle <myrrhperiwinkle@...labs.xyz>
To: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, 
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, 
 x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>
Cc: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org, 
 Roberto Ricci <io@...icci.it>, 
 Myrrh Periwinkle <myrrhperiwinkle@...labs.xyz>, stable@...r.kernel.org
Subject: [PATCH v2] x86/e820: Fix handling of subpage regions when
 calculating nosave ranges

The current implementation of e820__register_nosave_regions suffers from
multiple serious issues:
 - The end of last region is tracked by PFN, causing it to find holes
   that aren't there if two consecutive subpage regions are present
 - The nosave PFN ranges derived from holes are rounded out (instead of
   rounded in, which makes it inconsistent with how explicitly reserved
   regions are handled), which may cause us to erroneously mark some
   kernel memory as nosave

Fix this by:
 - Treating reserved regions as if they were holes, to ensure consistent
   handling
 - Tracking the end of the last RAM region by address instead of pages
 - Rounding in (instead of out) the nosave PFN ranges so we never mark
   any kernel memory as nosave

Fixes: e5540f875404 ("x86/boot/e820: Consolidate 'struct e820_entry *entry' local variable names")
Link: https://lore.kernel.org/all/Z_BDbwmFV6wxDPV1@desktop0a/
Tested-by: Roberto Ricci <io@...icci.it>
Reported-by: Roberto Ricci <io@...icci.it>
Closes: https://lore.kernel.org/all/Z4WFjBVHpndct7br@desktop0a/
Signed-off-by: Myrrh Periwinkle <myrrhperiwinkle@...labs.xyz>
Cc: stable@...r.kernel.org
---
The issue of the kernel failing to resume from hibernation after
kexec_load() is used is likely due to kexec-tools passing in a different
e820 memory map from the one provided by system firmware, causing the
e820 consistency check to fail. That issue is not addressed in this
patch and will need to be fixed in kexec-tools instead.

Changes in v2:
 - Updated author details
 - Rewrote commit message

Link to v1: https://lore.kernel.org/lkml/20250405-fix-e820-nosave-v1-1-162633199548@qtmlabs.xyz/

P.S. Does anybody know how to move b4 (https://b4.docs.kernel.org/)
state between machines?
---
 arch/x86/kernel/e820.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 57120f0749cc3c23844eeb36820705687e08bbf7..656ed7abd28de180b842a8d7993e9708f9f17026 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -753,22 +753,21 @@ void __init e820__memory_setup_extended(u64 phys_addr, u32 data_len)
 void __init e820__register_nosave_regions(unsigned long limit_pfn)
 {
 	int i;
-	unsigned long pfn = 0;
+	u64 last_addr = 0;
 
 	for (i = 0; i < e820_table->nr_entries; i++) {
 		struct e820_entry *entry = &e820_table->entries[i];
 
-		if (pfn < PFN_UP(entry->addr))
-			register_nosave_region(pfn, PFN_UP(entry->addr));
-
-		pfn = PFN_DOWN(entry->addr + entry->size);
-
 		if (entry->type != E820_TYPE_RAM)
-			register_nosave_region(PFN_UP(entry->addr), pfn);
+			continue;
 
-		if (pfn >= limit_pfn)
-			break;
+		if (last_addr < entry->addr)
+			register_nosave_region(PFN_UP(last_addr), PFN_DOWN(entry->addr));
+
+		last_addr = entry->addr + entry->size;
 	}
+
+	register_nosave_region(PFN_UP(last_addr), limit_pfn);
 }
 
 #ifdef CONFIG_ACPI

---
base-commit: a8662bcd2ff152bfbc751cab20f33053d74d0963
change-id: 20250405-fix-e820-nosave-f5cb985a9a61

Best regards,
-- 
Myrrh Periwinkle <myrrhperiwinkle@...labs.xyz>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ