From: Greg Kroah-Hartman Date: Tue, 14 Dec 2021 09:10:17 +0000 (+0100) Subject: drop x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch from 4.14 and... X-Git-Tag: v4.14.258~1 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1217359dcf7b630bf769e6bb9cd51484aca7f20e;p=thirdparty%2Fkernel%2Fstable-queue.git drop x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch from 4.14 and 4.19 queues --- diff --git a/queue-4.14/series b/queue-4.14/series index 006aa5efbbc..0dcee3640de 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -18,7 +18,6 @@ alsa-pcm-oss-handle-missing-errors-in-snd_pcm_oss_change_params.patch 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 diff --git a/queue-4.14/x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch b/queue-4.14/x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch deleted file mode 100644 index 42ac8b9e65a..00000000000 --- a/queue-4.14/x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch +++ /dev/null @@ -1,60 +0,0 @@ -From 1ff2fc02862d52e18fd3daabcfe840ec27e920a8 Mon Sep 17 00:00:00 2001 -From: Tom Lendacky -Date: Wed, 20 Oct 2021 13:02:11 -0500 -Subject: x86/sme: Explicitly map new EFI memmap table as encrypted - -From: Tom Lendacky - -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: # 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 -[ardb: incorporate Kconfig fix by Arnd] -Signed-off-by: Ard Biesheuvel -Signed-off-by: Greg Kroah-Hartman ---- - 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; diff --git a/queue-4.19/series b/queue-4.19/series index 4d62f38938e..c9e00e570b4 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -29,7 +29,6 @@ tracefs-have-new-files-inherit-the-ownership-of-their-parent.patch 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 diff --git a/queue-4.19/x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch b/queue-4.19/x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch deleted file mode 100644 index fde1e43e631..00000000000 --- a/queue-4.19/x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch +++ /dev/null @@ -1,60 +0,0 @@ -From 1ff2fc02862d52e18fd3daabcfe840ec27e920a8 Mon Sep 17 00:00:00 2001 -From: Tom Lendacky -Date: Wed, 20 Oct 2021 13:02:11 -0500 -Subject: x86/sme: Explicitly map new EFI memmap table as encrypted - -From: Tom Lendacky - -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: # 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 -[ardb: incorporate Kconfig fix by Arnd] -Signed-off-by: Ard Biesheuvel -Signed-off-by: Greg Kroah-Hartman ---- - 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;