linux-kernel - Re: [PATCH v5 19/32] x86/mm: Add support to access persistent memory in the clear

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 19 May 2017 14:52:58 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Borislav Petkov <bp@...en8.de>
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 5/16/2017 9:04 AM, Borislav Petkov wrote:
> 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...

I'll have to double-check this, but I believe that when persistent
memory is identified through the NFIT table it adds it as a resource
but doesn't add it as an e820 entry so I can't rely on the type being
returned as E820_TYPE_PMEM by e820__get_entry_type().

Thanks,
Tom

>