| 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
| ||
|
Message-ID: <174022537912.10177.11644259763508387652.tip-bot2@tip-bot2>
Date: Sat, 22 Feb 2025 11:56:19 -0000
From: "tip-bot2 for Dave Young" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: Dave Young <dyoung@...hat.com>, Ingo Molnar <mingo@...nel.org>,
Ashish Kalra <ashish.kalra@....com>, Sean Christopherson <seanjc@...gle.com>,
Joerg Roedel <jroedel@...e.de>, Baoquan He <bhe@...hat.com>,
Vivek Goyal <vgoyal@...hat.com>, Eric Biederman <ebiederm@...ssion.com>,
x86@...nel.org, linux-kernel@...r.kernel.org
Subject: [tip: x86/boot] x86/kexec: Export e820_table_kexec[] to sysfs
The following commit has been merged into the x86/boot branch of tip:
Commit-ID: a2498e5c453b3d8d054d77751487cd593332f8c2
Gitweb: https://git.kernel.org/tip/a2498e5c453b3d8d054d77751487cd593332f8c2
Author: Dave Young <dyoung@...hat.com>
AuthorDate: Tue, 28 Jan 2025 21:32:31 +08:00
Committer: Ingo Molnar <mingo@...nel.org>
CommitterDate: Sat, 22 Feb 2025 12:44:45 +01:00
x86/kexec: Export e820_table_kexec[] to sysfs
Previously the e820_table_kexec[] was exported to sysfs since kexec-tools uses
the memmap entries to prepare the e820 table for the new kernel.
The following commit, ~8 years ago, introduced e820_table_firmware[] and changed
the behavior to export the firmware table instead:
12df216c61c8 ("x86/boot/e820: Introduce the bootloader provided e820_table_firmware[] table")
Originally the kexec_file_load and kexec_load syscalls both used e820_table_kexec[].
Since the sysfs exported entries are from e820_table_firmware[] people
now need to tune both tables for kexec.
Restore the old behavior so the kexec_load and kexec_file_load syscalls work with
only one table update. The e820_table_firmware[] is used by hibernation kernel
code and it works without the sysfs exporting. Also remove the SEV
e820_table_firmware[] updating code.
Also update the code comments here and drop the comments about setup_data
reservation since it is not needed any more after this change was made
a year ago:
fc7f27cda843 ("x86/kexec: Do not update E820 kexec table for setup_data")
[ mingo: Tidy up the changelog and comments. ]
Signed-off-by: Dave Young <dyoung@...hat.com>
Signed-off-by: Ingo Molnar <mingo@...nel.org>
Cc: Ashish Kalra <ashish.kalra@....com>
Cc: Sean Christopherson <seanjc@...gle.com>
Cc: Joerg Roedel <jroedel@...e.de>
Cc: Baoquan He <bhe@...hat.com>
Cc: Vivek Goyal <vgoyal@...hat.com>
Cc: Eric Biederman <ebiederm@...ssion.com>
Link: https://lore.kernel.org/r/Z5jcb1GKhLvH8kDc@darkstar.users.ipa.redhat.com
---
arch/x86/kernel/e820.c | 20 ++++++++++----------
arch/x86/virt/svm/sev.c | 1 -
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 9fb67ab..57120f0 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -28,18 +28,13 @@
* the first 128 E820 memory entries in boot_params.e820_table and the remaining
* (if any) entries of the SETUP_E820_EXT nodes. We use this to:
*
- * - inform the user about the firmware's notion of memory layout
- * via /sys/firmware/memmap
- *
* - the hibernation code uses it to generate a kernel-independent CRC32
* checksum of the physical memory layout of a system.
*
* - 'e820_table_kexec': a slightly modified (by the kernel) firmware version
* passed to us by the bootloader - the major difference between
- * e820_table_firmware[] and this one is that, the latter marks the setup_data
- * list created by the EFI boot stub as reserved, so that kexec can reuse the
- * setup_data information in the second kernel. Besides, e820_table_kexec[]
- * might also be modified by the kexec itself to fake a mptable.
+ * e820_table_firmware[] and this one is that e820_table_kexec[]
+ * might be modified by the kexec itself to fake an mptable.
* We use this to:
*
* - kexec, which is a bootloader in disguise, uses the original E820
@@ -47,6 +42,11 @@
* can have a restricted E820 map while the kexec()-ed kexec-kernel
* can have access to full memory - etc.
*
+ * Export the memory layout via /sys/firmware/memmap. kexec-tools uses
+ * the entries to create an E820 table for the kexec kernel.
+ *
+ * kexec_file_load in-kernel code uses the table for the kexec kernel.
+ *
* - 'e820_table': this is the main E820 table that is massaged by the
* low level x86 platform code, or modified by boot parameters, before
* passed on to higher level MM layers.
@@ -1117,9 +1117,9 @@ void __init e820__reserve_resources(void)
res++;
}
- /* Expose the bootloader-provided memory layout to the sysfs. */
- for (i = 0; i < e820_table_firmware->nr_entries; i++) {
- struct e820_entry *entry = e820_table_firmware->entries + i;
+ /* Expose the kexec e820 table to the sysfs. */
+ for (i = 0; i < e820_table_kexec->nr_entries; i++) {
+ struct e820_entry *entry = e820_table_kexec->entries + i;
firmware_map_add_early(entry->addr, entry->addr + entry->size, e820_type_to_string(entry));
}
diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index 42e74a5..fc473ca 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -198,7 +198,6 @@ static void __init __snp_fixup_e820_tables(u64 pa)
pr_info("Reserving start/end of RMP table on a 2MB boundary [0x%016llx]\n", pa);
e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
e820__range_update_table(e820_table_kexec, pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
- e820__range_update_table(e820_table_firmware, pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
if (!memblock_is_region_reserved(pa, PMD_SIZE))
memblock_reserve(pa, PMD_SIZE);
}
Powered by blists - more mailing lists