[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170516140449.zmp3sm4krro55bbi@pd.tnic>
Date: Tue, 16 May 2017 16:04:49 +0200
From: Borislav Petkov <bp@...en8.de>
To: Tom Lendacky <thomas.lendacky@....com>
Cc: linux-arch@...r.kernel.org, linux-efi@...r.kernel.org,
kvm@...r.kernel.org, linux-doc@...r.kernel.org, x86@...nel.org,
kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
kasan-dev@...glegroups.com, linux-mm@...ck.org,
iommu@...ts.linux-foundation.org, Rik van Riel <riel@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Toshimitsu Kani <toshi.kani@....com>,
Arnd Bergmann <arnd@...db.de>,
Jonathan Corbet <corbet@....net>,
Matt Fleming <matt@...eblueprint.co.uk>,
"Michael S. Tsirkin" <mst@...hat.com>,
Joerg Roedel <joro@...tes.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Larry Woodman <lwoodman@...hat.com>,
Brijesh Singh <brijesh.singh@....com>,
Ingo Molnar <mingo@...hat.com>,
Andy Lutomirski <luto@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Alexander Potapenko <glider@...gle.com>,
Dave Young <dyoung@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: [PATCH v5 19/32] x86/mm: Add support to access persistent memory
in the clear
On Tue, Apr 18, 2017 at 04:19:42PM -0500, Tom Lendacky wrote:
> 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@....com>
> ---
> arch/x86/mm/ioremap.c | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index bce0604..55317ba 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -425,17 +425,46 @@ void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
> * Examine the physical address to determine if it is an area of memory
> * that should be mapped decrypted. If the memory is not part of the
> * kernel usable area it was accessed and created decrypted, so these
> - * areas should be mapped decrypted.
> + * areas should be mapped decrypted. And since the encryption key can
> + * change across reboots, persistent memory should also be mapped
> + * decrypted.
> */
> static bool memremap_should_map_decrypted(resource_size_t phys_addr,
> unsigned long size)
> {
> + int is_pmem;
> +
> + /*
> + * Check if the address is part of a persistent memory region.
> + * This check covers areas added by E820, EFI and ACPI.
> + */
> + is_pmem = region_intersects(phys_addr, size, IORESOURCE_MEM,
> + IORES_DESC_PERSISTENT_MEMORY);
> + if (is_pmem != REGION_DISJOINT)
> + return true;
> +
> + /*
> + * Check if the non-volatile attribute is set for an EFI
> + * reserved area.
> + */
> + if (efi_enabled(EFI_BOOT)) {
> + switch (efi_mem_type(phys_addr)) {
> + case EFI_RESERVED_TYPE:
> + if (efi_mem_attributes(phys_addr) & EFI_MEMORY_NV)
> + return true;
> + break;
> + default:
> + break;
> + }
> + }
> +
> /* Check if the address is outside kernel usable area */
> switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) {
> case E820_TYPE_RESERVED:
> case E820_TYPE_ACPI:
> case E820_TYPE_NVS:
> case E820_TYPE_UNUSABLE:
> + case E820_TYPE_PRAM:
Can't you simply add:
case E820_TYPE_PMEM:
here too and thus get rid of the region_intersects() thing above?
Because, for example, e820_type_to_iores_desc() maps E820_TYPE_PMEM to
IORES_DESC_PERSISTENT_MEMORY so those should be equivalent...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists