Currently memremap(MEMREMAP_WB) can produce decrypted/shared mapping:
memremap(MEMREMAP_WB) arch_memremap_wb() ioremap_cache() __ioremap_caller(.encrytped = false)
In such cases, the IORES_MAP_ENCRYPTED flag on the memory will determine if the resulting mapping is encrypted or decrypted.
Creating a decrypted mapping without explicit request from the caller is risky:
- It can inadvertently expose the guest's data and compromise the guest.
- Accessing private memory via shared/decrypted mapping on TDX will either trigger implicit conversion to shared or #VE (depending on VMM implementation).
Implicit conversion is destructive: subsequent access to the same memory via private mapping will trigger a hard-to-debug #VE crash.
The kernel already provides a way to request decrypted mapping explicitly via the MEMREMAP_DEC flag.
Modify memremap(MEMREMAP_WB) to produce encrypted/private mapping by default unless MEMREMAP_DEC is specified.
Fix the crash due to #VE on kexec in TDX guests if CONFIG_EISA is enabled.
Signed-off-by: Kirill A. Shutemov kirill.shutemov@linux.intel.com Cc: stable@vger.kernel.org # 6.11+ Cc: Tom Lendacky thomas.lendacky@amd.com Cc: Ashish Kalra ashish.kalra@amd.com Cc: "Maciej W. Rozycki" macro@orcam.me.uk --- arch/x86/include/asm/io.h | 3 +++ arch/x86/mm/ioremap.c | 8 ++++++++ 2 files changed, 11 insertions(+)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index ed580c7f9d0a..1a0dc2b2bf5b 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -175,6 +175,9 @@ extern void __iomem *ioremap_prot(resource_size_t offset, unsigned long size, un extern void __iomem *ioremap_encrypted(resource_size_t phys_addr, unsigned long size); #define ioremap_encrypted ioremap_encrypted
+void *arch_memremap_wb(phys_addr_t phys_addr, size_t size, unsigned long flags); +#define arch_memremap_wb arch_memremap_wb + /** * ioremap - map bus memory into CPU space * @offset: bus address of the memory diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 8d29163568a7..3c36f3f5e688 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -503,6 +503,14 @@ void iounmap(volatile void __iomem *addr) } EXPORT_SYMBOL(iounmap);
+void *arch_memremap_wb(phys_addr_t phys_addr, size_t size, unsigned long flags) +{ + if (flags & MEMREMAP_DEC) + return (void __force *)ioremap_cache(phys_addr, size); + + return (void __force *)ioremap_encrypted(phys_addr, size); +} + /* * Convert a physical pointer to a virtual kernel pointer for /dev/mem * access
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 95093e066cfdd18271619248b569c26cfc8fa024 Gitweb: https://git.kernel.org/tip/95093e066cfdd18271619248b569c26cfc8fa024 Author: Kirill A. Shutemov kirill.shutemov@linux.intel.com AuthorDate: Mon, 13 Jan 2025 15:14:59 +02:00 Committer: Borislav Petkov (AMD) bp@alien8.de CommitterDate: Mon, 13 Jan 2025 15:49:12 +01:00
x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default
Currently memremap(MEMREMAP_WB) can produce decrypted/shared mapping:
memremap(MEMREMAP_WB) arch_memremap_wb() ioremap_cache() __ioremap_caller(.encrytped = false)
In such cases, the IORES_MAP_ENCRYPTED flag on the memory will determine if the resulting mapping is encrypted or decrypted.
Creating a decrypted mapping without explicit request from the caller is risky:
- It can inadvertently expose the guest's data and compromise the guest.
- Accessing private memory via shared/decrypted mapping on TDX will either trigger implicit conversion to shared or #VE (depending on VMM implementation).
Implicit conversion is destructive: subsequent access to the same memory via private mapping will trigger a hard-to-debug #VE crash.
The kernel already provides a way to request decrypted mapping explicitly via the MEMREMAP_DEC flag.
Modify memremap(MEMREMAP_WB) to produce encrypted/private mapping by default unless MEMREMAP_DEC is specified.
Fix a crash due to #VE on kexec in TDX guests if CONFIG_EISA is enabled.
Signed-off-by: Kirill A. Shutemov kirill.shutemov@linux.intel.com Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Cc: stable@vger.kernel.org # 6.11+ Link: https://lore.kernel.org/r/20250113131459.2008123-3-kirill.shutemov@linux.int... --- arch/x86/include/asm/io.h | 3 +++ arch/x86/mm/ioremap.c | 8 ++++++++ 2 files changed, 11 insertions(+)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index ed580c7..1a0dc2b 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -175,6 +175,9 @@ extern void __iomem *ioremap_prot(resource_size_t offset, unsigned long size, un extern void __iomem *ioremap_encrypted(resource_size_t phys_addr, unsigned long size); #define ioremap_encrypted ioremap_encrypted
+void *arch_memremap_wb(phys_addr_t phys_addr, size_t size, unsigned long flags); +#define arch_memremap_wb arch_memremap_wb + /** * ioremap - map bus memory into CPU space * @offset: bus address of the memory diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 8d29163..3c36f3f 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -503,6 +503,14 @@ void iounmap(volatile void __iomem *addr) } EXPORT_SYMBOL(iounmap);
+void *arch_memremap_wb(phys_addr_t phys_addr, size_t size, unsigned long flags) +{ + if (flags & MEMREMAP_DEC) + return (void __force *)ioremap_cache(phys_addr, size); + + return (void __force *)ioremap_encrypted(phys_addr, size); +} + /* * Convert a physical pointer to a virtual kernel pointer for /dev/mem * access
On 1/13/25 07:14, Kirill A. Shutemov wrote:
Currently memremap(MEMREMAP_WB) can produce decrypted/shared mapping:
memremap(MEMREMAP_WB) arch_memremap_wb() ioremap_cache() __ioremap_caller(.encrytped = false)
In such cases, the IORES_MAP_ENCRYPTED flag on the memory will determine if the resulting mapping is encrypted or decrypted.
Creating a decrypted mapping without explicit request from the caller is risky:
It can inadvertently expose the guest's data and compromise the guest.
Accessing private memory via shared/decrypted mapping on TDX will either trigger implicit conversion to shared or #VE (depending on VMM implementation).
Implicit conversion is destructive: subsequent access to the same memory via private mapping will trigger a hard-to-debug #VE crash.
The kernel already provides a way to request decrypted mapping explicitly via the MEMREMAP_DEC flag.
Modify memremap(MEMREMAP_WB) to produce encrypted/private mapping by default unless MEMREMAP_DEC is specified.
Fix the crash due to #VE on kexec in TDX guests if CONFIG_EISA is enabled.
This patch causes my bare-metal system to crash during boot when using mem_encrypt=on:
[ 2.392934] efi: memattr: Entry type should be RuntimeServiceCode/Data [ 2.393731] efi: memattr: ! 0x214c42f01f1162a-0xee70ac7bd1a9c629 [type=2028324321|attr=0x6590648fa4209879] [ 2.394733] BUG: unable to handle page fault for address: ffffc900b4669017 [ 2.395729] #PF: supervisor read access in kernel mode [ 2.395729] #PF: error_code(0x0000) - not-present page [ 2.395729] PGD 8000100010067 P4D 8000100010067 PUD 0 [ 2.395729] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI [ 2.395729] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc7-sos-testing #1 [ 2.395729] Hardware name: ... [ 2.395729] RIP: 0010:efi_memattr_apply_permissions+0xa6/0x330 [ 2.395729] Code: 24 0f 48 8b 05 f3 30 a3 ff f6 c4 01 0f 85 66 02 00 00 31 db 4c 8d 6d 10 3b 5d 04 0f 83 4a 01 00 00 89 d8 0f af 45 08 4c 01 e8 <48> 8b 10 48 8b 70 08 4c 8b 40 18 48 89 54 24 10 48 8b 50 08 48 89 [ 2.395729] RSP: 0000:ffffffffb3803e18 EFLAGS: 00010296 [ 2.395729] RAX: ffffc900b4669017 RBX: 0000000000000001 RCX: 0000000000000000 [ 2.395729] RDX: 0000000000000000 RSI: ffffffffb3803cd8 RDI: 00000000ffffffff [ 2.395729] RBP: ffffc900000b5018 R08: 00000000fffeffff R09: 0000000000000001 [ 2.395729] R10: 00000000fffeffff R11: ffff894048a80000 R12: ffffffffb434f1c0 [ 2.395729] R13: ffffc900000b5028 R14: ec5be84ccfb8b000 R15: ffffffffb3803e28 [ 2.395729] FS: 0000000000000000(0000) GS:ffff894049000000(0000) knlGS:0000000000000000 [ 2.395729] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.395729] CR2: ffffc900b4669017 CR3: 0008006f43832001 CR4: 0000000000770ef0 [ 2.395729] PKRU: 55555554 [ 2.395729] Call Trace: [ 2.395729] <TASK> [ 2.395729] ? __die+0x1f/0x60 [ 2.395729] ? page_fault_oops+0x80/0x150 [ 2.395729] ? exc_page_fault+0x15f/0x170 [ 2.395729] ? asm_exc_page_fault+0x22/0x30 [ 2.395729] ? __pfx_efi_update_mem_attr+0x10/0x10 [ 2.395729] ? efi_memattr_apply_permissions+0xa6/0x330 [ 2.395729] ? efi_memattr_apply_permissions+0x254/0x330 [ 2.395729] __efi_enter_virtual_mode+0x166/0x250 [ 2.395729] efi_enter_virtual_mode+0x2d/0x50 [ 2.395729] start_kernel+0x5d7/0x670 [ 2.395729] x86_64_start_reservations+0x14/0x30 [ 2.395729] x86_64_start_kernel+0x79/0x80 [ 2.395729] common_startup_64+0x13e/0x141 [ 2.395729] </TASK> [ 2.395729] Modules linked in: [ 2.395729] CR2: ffffc900b4669017 [ 2.395729] ---[ end trace 0000000000000000 ]--- [ 2.395729] RIP: 0010:efi_memattr_apply_permissions+0xa6/0x330 [ 2.395729] Code: 24 0f 48 8b 05 f3 30 a3 ff f6 c4 01 0f 85 66 02 00 00 31 db 4c 8d 6d 10 3b 5d 04 0f 83 4a 01 00 00 89 d8 0f af 45 08 4c 01 e8 <48> 8b 10 48 8b 70 08 4c 8b 40 18 48 89 54 24 10 48 8b 50 08 48 89 [ 2.395729] RSP: 0000:ffffffffb3803e18 EFLAGS: 00010296 [ 2.395729] RAX: ffffc900b4669017 RBX: 0000000000000001 RCX: 0000000000000000 [ 2.395729] RDX: 0000000000000000 RSI: ffffffffb3803cd8 RDI: 00000000ffffffff [ 2.395729] RBP: ffffc900000b5018 R08: 00000000fffeffff R09: 0000000000000001 [ 2.395729] R10: 00000000fffeffff R11: ffff894048a80000 R12: ffffffffb434f1c0 [ 2.395729] R13: ffffc900000b5028 R14: ec5be84ccfb8b000 R15: ffffffffb3803e28 [ 2.395729] FS: 0000000000000000(0000) GS:ffff894049000000(0000) knlGS:0000000000000000 [ 2.395729] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.395729] CR2: ffffc900b4669017 CR3: 0008006f43832001 CR4: 0000000000770ef0 [ 2.395729] PKRU: 55555554 [ 2.395729] Kernel panic - not syncing: Fatal exception [ 2.395729] ---[ end Kernel panic - not syncing: Fatal exception ]---
Thanks, Tom
Signed-off-by: Kirill A. Shutemov kirill.shutemov@linux.intel.com Cc: stable@vger.kernel.org # 6.11+ Cc: Tom Lendacky thomas.lendacky@amd.com Cc: Ashish Kalra ashish.kalra@amd.com Cc: "Maciej W. Rozycki" macro@orcam.me.uk
arch/x86/include/asm/io.h | 3 +++ arch/x86/mm/ioremap.c | 8 ++++++++ 2 files changed, 11 insertions(+)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index ed580c7f9d0a..1a0dc2b2bf5b 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -175,6 +175,9 @@ extern void __iomem *ioremap_prot(resource_size_t offset, unsigned long size, un extern void __iomem *ioremap_encrypted(resource_size_t phys_addr, unsigned long size); #define ioremap_encrypted ioremap_encrypted +void *arch_memremap_wb(phys_addr_t phys_addr, size_t size, unsigned long flags); +#define arch_memremap_wb arch_memremap_wb
/**
- ioremap - map bus memory into CPU space
- @offset: bus address of the memory
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 8d29163568a7..3c36f3f5e688 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -503,6 +503,14 @@ void iounmap(volatile void __iomem *addr) } EXPORT_SYMBOL(iounmap); +void *arch_memremap_wb(phys_addr_t phys_addr, size_t size, unsigned long flags) +{
- if (flags & MEMREMAP_DEC)
return (void __force *)ioremap_cache(phys_addr, size);- return (void __force *)ioremap_encrypted(phys_addr, size);
+}
/*
- Convert a physical pointer to a virtual kernel pointer for /dev/mem
- access
On Mon, Jan 13, 2025 at 02:47:56PM -0600, Tom Lendacky wrote:
This patch causes my bare-metal system to crash during boot when using mem_encrypt=on:
[ 2.392934] efi: memattr: Entry type should be RuntimeServiceCode/Data [ 2.393731] efi: memattr: ! 0x214c42f01f1162a-0xee70ac7bd1a9c629 [type=2028324321|attr=0x6590648fa4209879] [ 2.394733] BUG: unable to handle page fault for address: ffffc900b4669017
A wild guess: looks like it tries to map EFI memory encrypted now...
Anyway, lemme zap. Those will have to go through the full motions of testing.
On Mon, Jan 13, 2025 at 02:47:56PM -0600, Tom Lendacky wrote:
On 1/13/25 07:14, Kirill A. Shutemov wrote:
Currently memremap(MEMREMAP_WB) can produce decrypted/shared mapping:
memremap(MEMREMAP_WB) arch_memremap_wb() ioremap_cache() __ioremap_caller(.encrytped = false)
In such cases, the IORES_MAP_ENCRYPTED flag on the memory will determine if the resulting mapping is encrypted or decrypted.
Creating a decrypted mapping without explicit request from the caller is risky:
It can inadvertently expose the guest's data and compromise the guest.
Accessing private memory via shared/decrypted mapping on TDX will either trigger implicit conversion to shared or #VE (depending on VMM implementation).
Implicit conversion is destructive: subsequent access to the same memory via private mapping will trigger a hard-to-debug #VE crash.
The kernel already provides a way to request decrypted mapping explicitly via the MEMREMAP_DEC flag.
Modify memremap(MEMREMAP_WB) to produce encrypted/private mapping by default unless MEMREMAP_DEC is specified.
Fix the crash due to #VE on kexec in TDX guests if CONFIG_EISA is enabled.
This patch causes my bare-metal system to crash during boot when using mem_encrypt=on:
[ 2.392934] efi: memattr: Entry type should be RuntimeServiceCode/Data [ 2.393731] efi: memattr: ! 0x214c42f01f1162a-0xee70ac7bd1a9c629 [type=2028324321|attr=0x6590648fa4209879]
Could you try if this helps?
diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c index c38b1a335590..b5051dcb7c1d 100644 --- a/drivers/firmware/efi/memattr.c +++ b/drivers/firmware/efi/memattr.c @@ -160,7 +160,7 @@ int __init efi_memattr_apply_permissions(struct mm_struct *mm, if (WARN_ON(!efi_enabled(EFI_MEMMAP))) return 0;
- tbl = memremap(efi_mem_attr_table, tbl_size, MEMREMAP_WB); + tbl = memremap(efi_mem_attr_table, tbl_size, MEMREMAP_WB | MEMREMAP_DEC); if (!tbl) { pr_err("Failed to map EFI Memory Attributes table @ 0x%lx\n", efi_mem_attr_table);
On 1/14/25 01:27, Kirill A. Shutemov wrote:
On Mon, Jan 13, 2025 at 02:47:56PM -0600, Tom Lendacky wrote:
On 1/13/25 07:14, Kirill A. Shutemov wrote:
Currently memremap(MEMREMAP_WB) can produce decrypted/shared mapping:
memremap(MEMREMAP_WB) arch_memremap_wb() ioremap_cache() __ioremap_caller(.encrytped = false)
In such cases, the IORES_MAP_ENCRYPTED flag on the memory will determine if the resulting mapping is encrypted or decrypted.
Creating a decrypted mapping without explicit request from the caller is risky:
It can inadvertently expose the guest's data and compromise the guest.
Accessing private memory via shared/decrypted mapping on TDX will either trigger implicit conversion to shared or #VE (depending on VMM implementation).
Implicit conversion is destructive: subsequent access to the same memory via private mapping will trigger a hard-to-debug #VE crash.
The kernel already provides a way to request decrypted mapping explicitly via the MEMREMAP_DEC flag.
Modify memremap(MEMREMAP_WB) to produce encrypted/private mapping by default unless MEMREMAP_DEC is specified.
Fix the crash due to #VE on kexec in TDX guests if CONFIG_EISA is enabled.
This patch causes my bare-metal system to crash during boot when using mem_encrypt=on:
[ 2.392934] efi: memattr: Entry type should be RuntimeServiceCode/Data [ 2.393731] efi: memattr: ! 0x214c42f01f1162a-0xee70ac7bd1a9c629 [type=2028324321|attr=0x6590648fa4209879]
Could you try if this helps?
diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c index c38b1a335590..b5051dcb7c1d 100644 --- a/drivers/firmware/efi/memattr.c +++ b/drivers/firmware/efi/memattr.c @@ -160,7 +160,7 @@ int __init efi_memattr_apply_permissions(struct mm_struct *mm, if (WARN_ON(!efi_enabled(EFI_MEMMAP))) return 0;
- tbl = memremap(efi_mem_attr_table, tbl_size, MEMREMAP_WB);
- tbl = memremap(efi_mem_attr_table, tbl_size, MEMREMAP_WB | MEMREMAP_DEC);
Well that would work for SME where EFI tables/data are not encrypted, but will break for SEV where EFI tables/data are encrypted.
Thanks, Tom
if (!tbl) { pr_err("Failed to map EFI Memory Attributes table @ 0x%lx\n", efi_mem_attr_table);
On Tue, Jan 14, 2025 at 08:33:39AM -0600, Tom Lendacky wrote:
On 1/14/25 01:27, Kirill A. Shutemov wrote:
On Mon, Jan 13, 2025 at 02:47:56PM -0600, Tom Lendacky wrote:
On 1/13/25 07:14, Kirill A. Shutemov wrote:
Currently memremap(MEMREMAP_WB) can produce decrypted/shared mapping:
memremap(MEMREMAP_WB) arch_memremap_wb() ioremap_cache() __ioremap_caller(.encrytped = false)
In such cases, the IORES_MAP_ENCRYPTED flag on the memory will determine if the resulting mapping is encrypted or decrypted.
Creating a decrypted mapping without explicit request from the caller is risky:
It can inadvertently expose the guest's data and compromise the guest.
Accessing private memory via shared/decrypted mapping on TDX will either trigger implicit conversion to shared or #VE (depending on VMM implementation).
Implicit conversion is destructive: subsequent access to the same memory via private mapping will trigger a hard-to-debug #VE crash.
The kernel already provides a way to request decrypted mapping explicitly via the MEMREMAP_DEC flag.
Modify memremap(MEMREMAP_WB) to produce encrypted/private mapping by default unless MEMREMAP_DEC is specified.
Fix the crash due to #VE on kexec in TDX guests if CONFIG_EISA is enabled.
This patch causes my bare-metal system to crash during boot when using mem_encrypt=on:
[ 2.392934] efi: memattr: Entry type should be RuntimeServiceCode/Data [ 2.393731] efi: memattr: ! 0x214c42f01f1162a-0xee70ac7bd1a9c629 [type=2028324321|attr=0x6590648fa4209879]
Could you try if this helps?
diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c index c38b1a335590..b5051dcb7c1d 100644 --- a/drivers/firmware/efi/memattr.c +++ b/drivers/firmware/efi/memattr.c @@ -160,7 +160,7 @@ int __init efi_memattr_apply_permissions(struct mm_struct *mm, if (WARN_ON(!efi_enabled(EFI_MEMMAP))) return 0;
- tbl = memremap(efi_mem_attr_table, tbl_size, MEMREMAP_WB);
- tbl = memremap(efi_mem_attr_table, tbl_size, MEMREMAP_WB | MEMREMAP_DEC);
Well that would work for SME where EFI tables/data are not encrypted, but will break for SEV where EFI tables/data are encrypted.
Hm. Why would it break for SEV? It brings the situation back to what it was before the patch.
Note that that __ioremap_caller() would still check io_desc.flags before mapping it as decrypted.
On 1/14/25 08:44, Kirill A. Shutemov wrote:
On Tue, Jan 14, 2025 at 08:33:39AM -0600, Tom Lendacky wrote:
On 1/14/25 01:27, Kirill A. Shutemov wrote:
On Mon, Jan 13, 2025 at 02:47:56PM -0600, Tom Lendacky wrote:
On 1/13/25 07:14, Kirill A. Shutemov wrote:
Currently memremap(MEMREMAP_WB) can produce decrypted/shared mapping:
memremap(MEMREMAP_WB) arch_memremap_wb() ioremap_cache() __ioremap_caller(.encrytped = false)
In such cases, the IORES_MAP_ENCRYPTED flag on the memory will determine if the resulting mapping is encrypted or decrypted.
Creating a decrypted mapping without explicit request from the caller is risky:
It can inadvertently expose the guest's data and compromise the guest.
Accessing private memory via shared/decrypted mapping on TDX will either trigger implicit conversion to shared or #VE (depending on VMM implementation).
Implicit conversion is destructive: subsequent access to the same memory via private mapping will trigger a hard-to-debug #VE crash.
The kernel already provides a way to request decrypted mapping explicitly via the MEMREMAP_DEC flag.
Modify memremap(MEMREMAP_WB) to produce encrypted/private mapping by default unless MEMREMAP_DEC is specified.
Fix the crash due to #VE on kexec in TDX guests if CONFIG_EISA is enabled.
This patch causes my bare-metal system to crash during boot when using mem_encrypt=on:
[ 2.392934] efi: memattr: Entry type should be RuntimeServiceCode/Data [ 2.393731] efi: memattr: ! 0x214c42f01f1162a-0xee70ac7bd1a9c629 [type=2028324321|attr=0x6590648fa4209879]
Could you try if this helps?
diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c index c38b1a335590..b5051dcb7c1d 100644 --- a/drivers/firmware/efi/memattr.c +++ b/drivers/firmware/efi/memattr.c @@ -160,7 +160,7 @@ int __init efi_memattr_apply_permissions(struct mm_struct *mm, if (WARN_ON(!efi_enabled(EFI_MEMMAP))) return 0;
- tbl = memremap(efi_mem_attr_table, tbl_size, MEMREMAP_WB);
- tbl = memremap(efi_mem_attr_table, tbl_size, MEMREMAP_WB | MEMREMAP_DEC);
Well that would work for SME where EFI tables/data are not encrypted, but will break for SEV where EFI tables/data are encrypted.
Hm. Why would it break for SEV? It brings the situation back to what it was before the patch.
Ah, true. I can try it and see how much further SME gets. Hopefully it doesn't turn into a whack-a-mole thing.
Thanks, Tom
Note that that __ioremap_caller() would still check io_desc.flags before mapping it as decrypted.
linux-stable-mirror@lists.linaro.org
-
Borislav Petkov -
Kirill A. Shutemov -
tip-bot2 for Kirill A. Shutemov -
Tom Lendacky