[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1532becb-f2be-4458-5d34-77070f2c5e2d@amd.com>
Date: Mon, 13 Jan 2025 14:47:56 -0600
From: Tom Lendacky <thomas.lendacky@....com>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
Andy Lutomirski <luto@...nel.org>
Cc: Albert Ou <aou@...s.berkeley.edu>, Alexei Starovoitov <ast@...nel.org>,
Andrea Parri <parri.andrea@...il.com>, Arnd Bergmann <arnd@...db.de>,
Daniel Borkmann <daniel@...earbox.net>, Eric Chan <ericchancf@...gle.com>,
Jason Gunthorpe <jgg@...pe.ca>, Kai Huang <kai.huang@...el.com>,
Kefeng Wang <wangkefeng.wang@...wei.com>,
Kent Overstreet <kent.overstreet@...ux.dev>,
Palmer Dabbelt <palmer@...osinc.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Russell King <linux@...linux.org.uk>,
Samuel Holland <samuel.holland@...ive.com>,
Suren Baghdasaryan <surenb@...gle.com>, Yuntao Wang <ytcoode@...il.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org, stable@...r.kernel.org,
Ashish Kalra <ashish.kalra@....com>, "Maciej W. Rozycki" <macro@...am.me.uk>
Subject: Re: [PATCHv3 2/2] x86/mm: Make memremap(MEMREMAP_WB) map memory as
encrypted by default
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@...ux.intel.com>
> Cc: stable@...r.kernel.org # 6.11+
> Cc: Tom Lendacky <thomas.lendacky@....com>
> Cc: Ashish Kalra <ashish.kalra@....com>
> Cc: "Maciej W. Rozycki" <macro@...am.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
Powered by blists - more mailing lists