* [PATCH] mm/memremap.c: map FS_DAX device memory as decrypted
@ 2022-11-02 16:07 Pankaj Gupta
2022-11-02 19:03 ` Gupta, Pankaj
2022-11-02 20:05 ` Andrew Morton
0 siblings, 2 replies; 5+ messages in thread
From: Pankaj Gupta @ 2022-11-02 16:07 UTC (permalink / raw)
To: linux-mm, linux-kernel; +Cc: dan.j.williams, thomas.lendacky, pankaj.gupta
virtio_pmem use devm_memremap_pages() to map the device memory.
By default this memory is mapped as encrypted with SEV. Guest
reboot changes the current encryption key and guest no longer
properly decrypts the FSDAX device meta data.
Mark the corresponding device memory region for FSDAX devices
(mapped with memremap_pages) as decrypted to retain the persistent
memory property.
Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com>
---
mm/memremap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/memremap.c b/mm/memremap.c
index 421bec3a29ee..08cbf54fe037 100644
--- a/mm/memremap.c
+++ b/mm/memremap.c
@@ -335,6 +335,7 @@ void *memremap_pages(struct dev_pagemap *pgmap, int nid)
WARN(1, "File system DAX not supported\n");
return ERR_PTR(-EINVAL);
}
+ params.pgprot = pgprot_decrypted(params.pgprot);
break;
case MEMORY_DEVICE_GENERIC:
break;
--
2.34.1
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] mm/memremap.c: map FS_DAX device memory as decrypted
2022-11-02 16:07 [PATCH] mm/memremap.c: map FS_DAX device memory as decrypted Pankaj Gupta
@ 2022-11-02 19:03 ` Gupta, Pankaj
2022-11-02 20:05 ` Andrew Morton
1 sibling, 0 replies; 5+ messages in thread
From: Gupta, Pankaj @ 2022-11-02 19:03 UTC (permalink / raw)
To: linux-mm, linux-kernel
Cc: Andrew Morton, dan.j.williams, thomas.lendacky, pankaj.gupta
+Cc Andrew [forgot to add earlier]
> virtio_pmem use devm_memremap_pages() to map the device memory.
> By default this memory is mapped as encrypted with SEV. Guest
> reboot changes the current encryption key and guest no longer
> properly decrypts the FSDAX device meta data.
>
> Mark the corresponding device memory region for FSDAX devices
> (mapped with memremap_pages) as decrypted to retain the persistent
> memory property.
>
> Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com>
> ---
> mm/memremap.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/memremap.c b/mm/memremap.c
> index 421bec3a29ee..08cbf54fe037 100644
> --- a/mm/memremap.c
> +++ b/mm/memremap.c
> @@ -335,6 +335,7 @@ void *memremap_pages(struct dev_pagemap *pgmap, int nid)
> WARN(1, "File system DAX not supported\n");
> return ERR_PTR(-EINVAL);
> }
> + params.pgprot = pgprot_decrypted(params.pgprot);
> break;
> case MEMORY_DEVICE_GENERIC:
> break;
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] mm/memremap.c: map FS_DAX device memory as decrypted
2022-11-02 16:07 [PATCH] mm/memremap.c: map FS_DAX device memory as decrypted Pankaj Gupta
2022-11-02 19:03 ` Gupta, Pankaj
@ 2022-11-02 20:05 ` Andrew Morton
2022-11-03 7:55 ` Gupta, Pankaj
1 sibling, 1 reply; 5+ messages in thread
From: Andrew Morton @ 2022-11-02 20:05 UTC (permalink / raw)
To: Pankaj Gupta; +Cc: linux-mm, linux-kernel, dan.j.williams, thomas.lendacky
On Wed, 2 Nov 2022 11:07:28 -0500 Pankaj Gupta <pankaj.gupta@amd.com> wrote:
> virtio_pmem use devm_memremap_pages() to map the device memory.
> By default this memory is mapped as encrypted with SEV. Guest
> reboot changes the current encryption key and guest no longer
> properly decrypts the FSDAX device meta data.
>
> Mark the corresponding device memory region for FSDAX devices
> (mapped with memremap_pages) as decrypted to retain the persistent
> memory property.
>
> ...
>
> --- a/mm/memremap.c
> +++ b/mm/memremap.c
> @@ -335,6 +335,7 @@ void *memremap_pages(struct dev_pagemap *pgmap, int nid)
> WARN(1, "File system DAX not supported\n");
> return ERR_PTR(-EINVAL);
> }
> + params.pgprot = pgprot_decrypted(params.pgprot);
> break;
> case MEMORY_DEVICE_GENERIC:
> break;
Should this be backported into earlier kernels?
Is b7b3c01b19159 a suitable Fixes: target?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] mm/memremap.c: map FS_DAX device memory as decrypted
2022-11-02 20:05 ` Andrew Morton
@ 2022-11-03 7:55 ` Gupta, Pankaj
2022-11-04 23:32 ` Andrew Morton
0 siblings, 1 reply; 5+ messages in thread
From: Gupta, Pankaj @ 2022-11-03 7:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, linux-kernel, dan.j.williams, thomas.lendacky
Hi Andrew,
>> virtio_pmem use devm_memremap_pages() to map the device memory.
>> By default this memory is mapped as encrypted with SEV. Guest
>> reboot changes the current encryption key and guest no longer
>> properly decrypts the FSDAX device meta data.
>>
>> Mark the corresponding device memory region for FSDAX devices
>> (mapped with memremap_pages) as decrypted to retain the persistent
>> memory property.
>>
>> ...
>>
>> --- a/mm/memremap.c
>> +++ b/mm/memremap.c
>> @@ -335,6 +335,7 @@ void *memremap_pages(struct dev_pagemap *pgmap, int nid)
>> WARN(1, "File system DAX not supported\n");
>> return ERR_PTR(-EINVAL);
>> }
>> + params.pgprot = pgprot_decrypted(params.pgprot);
>> break;
>> case MEMORY_DEVICE_GENERIC:
>> break;
>
> Should this be backported into earlier kernels?
Yes, kernel >= 5.10 for clean back-port as it contains the below commit.
>
> Is b7b3c01b19159 a suitable Fixes: target?
Not very sure. But seems like the right commit for fixes tag as the
target code is moved in this commit with multiple range support addition.
Should I send a v2 with fixes & stable kernel fixes tag?
Thanks,
Pankaj
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] mm/memremap.c: map FS_DAX device memory as decrypted
2022-11-03 7:55 ` Gupta, Pankaj
@ 2022-11-04 23:32 ` Andrew Morton
0 siblings, 0 replies; 5+ messages in thread
From: Andrew Morton @ 2022-11-04 23:32 UTC (permalink / raw)
To: Gupta, Pankaj; +Cc: linux-mm, linux-kernel, dan.j.williams, thomas.lendacky
On Thu, 3 Nov 2022 08:55:40 +0100 "Gupta, Pankaj" <pankaj.gupta@amd.com> wrote:
> > Should this be backported into earlier kernels?
>
> Yes, kernel >= 5.10 for clean back-port as it contains the below commit.
>
> >
> > Is b7b3c01b19159 a suitable Fixes: target?
>
> Not very sure. But seems like the right commit for fixes tag as the
> target code is moved in this commit with multiple range support addition.
>
> Should I send a v2 with fixes & stable kernel fixes tag?
That's OK thanks - I made those changes to my copy.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-11-04 23:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-02 16:07 [PATCH] mm/memremap.c: map FS_DAX device memory as decrypted Pankaj Gupta
2022-11-02 19:03 ` Gupta, Pankaj
2022-11-02 20:05 ` Andrew Morton
2022-11-03 7:55 ` Gupta, Pankaj
2022-11-04 23:32 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox