| Message ID | 20170216154521.19244.89502.stgit@tlendack-t1.amdoffice.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> -----Original Message----- > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel- > owner@vger.kernel.org] On Behalf Of Tom Lendacky > Sent: Thursday, February 16, 2017 9:45 AM > Subject: [RFC PATCH v4 15/28] Add support to access persistent memory in > the clear > > Persistent memory is expected to persist across reboots. The encryption > key used by SME will change across reboots which will result in corrupted > persistent memory. Persistent memory is handed out by block devices > through memory remapping functions, so be sure not to map this memory as > encrypted. The system might be able to save and restore the correct encryption key for a region of persistent memory, in which case it does need to be mapped as encrypted. This might deserve a new EFI_MEMORY_ENCRYPTED attribute bit so the system firmware can communicate that information to the OS (in the UEFI memory map and the ACPI NFIT SPA Range structures). It wouldn't likely ever be added to the E820h table - ACPI 6.1 already obsoleted the Extended Attribute for AddressRangeNonVolatile. > > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> > --- > arch/x86/mm/ioremap.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c > index b0ff6bc..c6cb921 100644 > --- a/arch/x86/mm/ioremap.c > +++ b/arch/x86/mm/ioremap.c > @@ -498,6 +498,8 @@ static bool > memremap_should_map_encrypted(resource_size_t phys_addr, > case E820_TYPE_ACPI: > case E820_TYPE_NVS: > case E820_TYPE_UNUSABLE: > + case E820_TYPE_PMEM: > + case E820_TYPE_PRAM: > return false; > default: > break; E820_TYPE_RESERVED is also used to report persistent memory in some systems (patch 16 adds that for other reasons). You might want to intercept the persistent memory types in the efi_mem_type(phys_addr) switch statement earlier in the function as well. https://lkml.org/lkml/2017/3/13/357 recently mentioned that "in qemu hotpluggable memory isn't put into E820," with the latest information only in the UEFI memory map. Persistent memory can be reported there as: * EfiReservedMemoryType type with the EFI_MEMORY_NV attribute * EfiPersistentMemory type with the EFI_MEMORY_NV attribute Even the UEFI memory map is not authoritative, though. To really determine what is in these regions requires parsing the ACPI NFIT SPA Ranges structures. Parts of the E820 or UEFI regions could be reported as volatile there and should thus be encrypted. --- Robert Elliott, HPE Persistent Memory
On 3/17/2017 5:58 PM, Elliott, Robert (Persistent Memory) wrote: > > >> -----Original Message----- >> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel- >> owner@vger.kernel.org] On Behalf Of Tom Lendacky >> Sent: Thursday, February 16, 2017 9:45 AM >> Subject: [RFC PATCH v4 15/28] Add support to access persistent memory in >> the clear >> >> Persistent memory is expected to persist across reboots. The encryption >> key used by SME will change across reboots which will result in corrupted >> persistent memory. Persistent memory is handed out by block devices >> through memory remapping functions, so be sure not to map this memory as >> encrypted. > > The system might be able to save and restore the correct encryption key for a > region of persistent memory, in which case it does need to be mapped as > encrypted. If the OS could get some indication that BIOS/UEFI has saved and restored the encryption key, then it could be mapped encrypted. > > This might deserve a new EFI_MEMORY_ENCRYPTED attribute bit so the > system firmware can communicate that information to the OS (in the > UEFI memory map and the ACPI NFIT SPA Range structures). It wouldn't > likely ever be added to the E820h table - ACPI 6.1 already obsoleted the > Extended Attribute for AddressRangeNonVolatile. An attribute bit in some form would be a nice way to inform the OS that the persistent memory can be mapped encrypted. > >> >> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> >> --- >> arch/x86/mm/ioremap.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c >> index b0ff6bc..c6cb921 100644 >> --- a/arch/x86/mm/ioremap.c >> +++ b/arch/x86/mm/ioremap.c >> @@ -498,6 +498,8 @@ static bool >> memremap_should_map_encrypted(resource_size_t phys_addr, >> case E820_TYPE_ACPI: >> case E820_TYPE_NVS: >> case E820_TYPE_UNUSABLE: >> + case E820_TYPE_PMEM: >> + case E820_TYPE_PRAM: >> return false; >> default: >> break; > > E820_TYPE_RESERVED is also used to report persistent memory in > some systems (patch 16 adds that for other reasons). > > You might want to intercept the persistent memory types in the > efi_mem_type(phys_addr) switch statement earlier in the function > as well. https://lkml.org/lkml/2017/3/13/357 recently mentioned that > "in qemu hotpluggable memory isn't put into E820," with the latest > information only in the UEFI memory map. > > Persistent memory can be reported there as: > * EfiReservedMemoryType type with the EFI_MEMORY_NV attribute > * EfiPersistentMemory type with the EFI_MEMORY_NV attribute > > Even the UEFI memory map is not authoritative, though. To really > determine what is in these regions requires parsing the ACPI NFIT > SPA Ranges structures. Parts of the E820 or UEFI regions could be > reported as volatile there and should thus be encrypted. Thanks for the details on this. I'll take a closer look at this and update the checks appropriately. Thanks, Tom > > --- > Robert Elliott, HPE Persistent Memory > > >
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index b0ff6bc..c6cb921 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -498,6 +498,8 @@ static bool memremap_should_map_encrypted(resource_size_t phys_addr, case E820_TYPE_ACPI: case E820_TYPE_NVS: case E820_TYPE_UNUSABLE: + case E820_TYPE_PMEM: + case E820_TYPE_PRAM: return false; default: break;
Persistent memory is expected to persist across reboots. The encryption key used by SME will change across reboots which will result in corrupted persistent memory. Persistent memory is handed out by block devices through memory remapping functions, so be sure not to map this memory as encrypted. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> --- arch/x86/mm/ioremap.c | 2 ++ 1 file changed, 2 insertions(+)