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
--
2.45.2On 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:
> 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);
--
Kiryl Shutsemau / Kirill A. Shutemov
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. -- Kiryl Shutsemau / Kirill A. Shutemov
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. >
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.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
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.intel.com
---
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© 2016 - 2025 Red Hat, Inc.