Re: [PATCHv3 2/2] x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default

Re: [PATCHv3 2/2] x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default

[Tom Lendacky]

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

Re: [PATCHv3 2/2] x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default

[Borislav Petkov]

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

Re: [PATCHv3 2/2] x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default

[Kirill A. Shutemov]

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

Re: [PATCHv3 2/2] x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default

[Tom Lendacky]

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);

Re: [PATCHv3 2/2] x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default

[Kirill A. Shutemov]

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

Re: [PATCHv3 2/2] x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default

[Tom Lendacky]

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.
> 

Re: [PATCHv3 2/2] x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default

[Kirill A. Shutemov]

On Tue, Jan 14, 2025 at 10:54:53AM -0600, Tom Lendacky wrote:
> On 1/14/25 09:06, Tom Lendacky wrote:
> > 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.
> 
> Unfortunately, it is turning into a whack-a-mole thing.
> 
> But it looks the following works for SME:
> 
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 3c36f3f5e688..ff3cd5fc8508 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -505,7 +505,7 @@ EXPORT_SYMBOL(iounmap);
>  
>  void *arch_memremap_wb(phys_addr_t phys_addr, size_t size, unsigned long flags)
>  {
> -	if (flags & MEMREMAP_DEC)
> +	if (flags & MEMREMAP_DEC || cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
>  		return (void __force *)ioremap_cache(phys_addr, size);
>  
>  	return (void __force *)ioremap_encrypted(phys_addr, size);
> 
> 
> I haven't had a chance to test the series on SEV, yet.

Please do.

I am okay with the change above. Borislav, is it acceptable direction for
you?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Re: [PATCHv3 2/2] x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default

[Borislav Petkov]

On Wed, Jan 15, 2025 at 12:23:54PM +0200, Kirill A. Shutemov wrote:
> I am okay with the change above. Borislav, is it acceptable direction for
> you?

Yes, Tom and I have been talking offlist about making the *map code figure out
itself what type of encryption setting it should use, based on the platform.
It'll need a proper analysis, though, what all the possible usages are to see
whether that scheme would be adequeate.

Something to experiment with after the merge window.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette