tracefs-have-new-files-inherit-the-ownership-of-their-parent.patch
can-pch_can-pch_can_rx_normal-fix-use-after-free.patch
can-m_can-disable-and-ignore-elo-interrupt.patch
-x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch
libata-add-horkage-for-asmedia-1092.patch
wait-add-wake_up_pollfree.patch
binder-use-wake_up_pollfree.patch
+++ /dev/null
-From 1ff2fc02862d52e18fd3daabcfe840ec27e920a8 Mon Sep 17 00:00:00 2001
-From: Tom Lendacky <thomas.lendacky@amd.com>
-Date: Wed, 20 Oct 2021 13:02:11 -0500
-Subject: x86/sme: Explicitly map new EFI memmap table as encrypted
-
-From: Tom Lendacky <thomas.lendacky@amd.com>
-
-commit 1ff2fc02862d52e18fd3daabcfe840ec27e920a8 upstream.
-
-Reserving memory using efi_mem_reserve() calls into the x86
-efi_arch_mem_reserve() function. This function will insert a new EFI
-memory descriptor into the EFI memory map representing the area of
-memory to be reserved and marking it as EFI runtime memory. As part
-of adding this new entry, a new EFI memory map is allocated and mapped.
-The mapping is where a problem can occur. This new memory map is mapped
-using early_memremap() and generally mapped encrypted, unless the new
-memory for the mapping happens to come from an area of memory that is
-marked as EFI_BOOT_SERVICES_DATA memory. In this case, the new memory will
-be mapped unencrypted. However, during replacement of the old memory map,
-efi_mem_type() is disabled, so the new memory map will now be long-term
-mapped encrypted (in efi.memmap), resulting in the map containing invalid
-data and causing the kernel boot to crash.
-
-Since it is known that the area will be mapped encrypted going forward,
-explicitly map the new memory map as encrypted using early_memremap_prot().
-
-Cc: <stable@vger.kernel.org> # 4.14.x
-Fixes: 8f716c9b5feb ("x86/mm: Add support to access boot related data in the clear")
-Link: https://lore.kernel.org/all/ebf1eb2940405438a09d51d121ec0d02c8755558.1634752931.git.thomas.lendacky@amd.com/
-Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
-[ardb: incorporate Kconfig fix by Arnd]
-Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- arch/x86/Kconfig | 1 +
- arch/x86/platform/efi/quirks.c | 3 ++-
- 2 files changed, 3 insertions(+), 1 deletion(-)
-
---- a/arch/x86/Kconfig
-+++ b/arch/x86/Kconfig
-@@ -1903,6 +1903,7 @@ config EFI
- depends on ACPI
- select UCS2_STRING
- select EFI_RUNTIME_WRAPPERS
-+ select ARCH_USE_MEMREMAP_PROT
- ---help---
- This enables the kernel to use EFI runtime services that are
- available (such as the EFI variable services).
---- a/arch/x86/platform/efi/quirks.c
-+++ b/arch/x86/platform/efi/quirks.c
-@@ -276,7 +276,8 @@ void __init efi_arch_mem_reserve(phys_ad
- return;
- }
-
-- new = early_memremap(new_phys, new_size);
-+ new = early_memremap_prot(new_phys, new_size,
-+ pgprot_val(pgprot_encrypted(FIXMAP_PAGE_NORMAL)));
- if (!new) {
- pr_err("Failed to map new boot services memmap\n");
- return;
clk-qcom-regmap-mux-fix-parent-clock-lookup.patch
can-pch_can-pch_can_rx_normal-fix-use-after-free.patch
can-m_can-disable-and-ignore-elo-interrupt.patch
-x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch
libata-add-horkage-for-asmedia-1092.patch
wait-add-wake_up_pollfree.patch
binder-use-wake_up_pollfree.patch
+++ /dev/null
-From 1ff2fc02862d52e18fd3daabcfe840ec27e920a8 Mon Sep 17 00:00:00 2001
-From: Tom Lendacky <thomas.lendacky@amd.com>
-Date: Wed, 20 Oct 2021 13:02:11 -0500
-Subject: x86/sme: Explicitly map new EFI memmap table as encrypted
-
-From: Tom Lendacky <thomas.lendacky@amd.com>
-
-commit 1ff2fc02862d52e18fd3daabcfe840ec27e920a8 upstream.
-
-Reserving memory using efi_mem_reserve() calls into the x86
-efi_arch_mem_reserve() function. This function will insert a new EFI
-memory descriptor into the EFI memory map representing the area of
-memory to be reserved and marking it as EFI runtime memory. As part
-of adding this new entry, a new EFI memory map is allocated and mapped.
-The mapping is where a problem can occur. This new memory map is mapped
-using early_memremap() and generally mapped encrypted, unless the new
-memory for the mapping happens to come from an area of memory that is
-marked as EFI_BOOT_SERVICES_DATA memory. In this case, the new memory will
-be mapped unencrypted. However, during replacement of the old memory map,
-efi_mem_type() is disabled, so the new memory map will now be long-term
-mapped encrypted (in efi.memmap), resulting in the map containing invalid
-data and causing the kernel boot to crash.
-
-Since it is known that the area will be mapped encrypted going forward,
-explicitly map the new memory map as encrypted using early_memremap_prot().
-
-Cc: <stable@vger.kernel.org> # 4.14.x
-Fixes: 8f716c9b5feb ("x86/mm: Add support to access boot related data in the clear")
-Link: https://lore.kernel.org/all/ebf1eb2940405438a09d51d121ec0d02c8755558.1634752931.git.thomas.lendacky@amd.com/
-Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
-[ardb: incorporate Kconfig fix by Arnd]
-Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- arch/x86/Kconfig | 1 +
- arch/x86/platform/efi/quirks.c | 3 ++-
- 2 files changed, 3 insertions(+), 1 deletion(-)
-
---- a/arch/x86/Kconfig
-+++ b/arch/x86/Kconfig
-@@ -1953,6 +1953,7 @@ config EFI
- depends on ACPI
- select UCS2_STRING
- select EFI_RUNTIME_WRAPPERS
-+ select ARCH_USE_MEMREMAP_PROT
- ---help---
- This enables the kernel to use EFI runtime services that are
- available (such as the EFI variable services).
---- a/arch/x86/platform/efi/quirks.c
-+++ b/arch/x86/platform/efi/quirks.c
-@@ -278,7 +278,8 @@ void __init efi_arch_mem_reserve(phys_ad
- return;
- }
-
-- new = early_memremap(new_phys, new_size);
-+ new = early_memremap_prot(new_phys, new_size,
-+ pgprot_val(pgprot_encrypted(FIXMAP_PAGE_NORMAL)));
- if (!new) {
- pr_err("Failed to map new boot services memmap\n");
- return;
projects / thirdparty / kernel / stable-queue.git / commitdiff
