Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752300AbcD3GOy (ORCPT ); Sat, 30 Apr 2016 02:14:54 -0400 Received: from g9t1613g.houston.hp.com ([15.240.0.71]:34902 "EHLO g9t1613g.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751548AbcD3GOv (ORCPT ); Sat, 30 Apr 2016 02:14:51 -0400 From: "Elliott, Robert (Persistent Memory)" To: Tom Lendacky , "linux-arch@vger.kernel.org" , "linux-efi@vger.kernel.org" , "kvm@vger.kernel.org" , "linux-doc@vger.kernel.org" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "kasan-dev@googlegroups.com" , "linux-mm@kvack.org" , "iommu@lists.linux-foundation.org" CC: =?utf-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , "Konrad Rzeszutek Wilk" , Paolo Bonzini , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , "Thomas Gleixner" , Dmitry Vyukov Subject: RE: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD) Thread-Topic: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD) Thread-Index: AQHRoA7akq/dosLVYUagaO4x9OsVKJ+iC7dA Date: Sat, 30 Apr 2016 06:13:33 +0000 Message-ID: <94D0CD8314A33A4D9D801C0FE68B402963918FDA@G4W3296.americas.hpqcorp.net> References: <20160426225553.13567.19459.stgit@tlendack-t1.amdoffice.net> In-Reply-To: <20160426225553.13567.19459.stgit@tlendack-t1.amdoffice.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.216.65.182] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u3U6F18P006192 Content-Length: 1394 Lines: 36 > -----Original Message----- > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel- > owner@vger.kernel.org] On Behalf Of Tom Lendacky > Sent: Tuesday, April 26, 2016 5:56 PM > Subject: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD) > > This RFC patch series provides support for AMD's new Secure Memory > Encryption (SME) feature. > > SME can be used to mark individual pages of memory as encrypted through the > page tables. A page of memory that is marked encrypted will be automatically > decrypted when read from DRAM and will be automatically encrypted when > written to DRAM. Details on SME can found in the links below. > ... > ... Certain data must be accounted for > as having been placed in memory before SME was enabled (EFI, initrd, etc.) > and accessed accordingly. > ... > x86/efi: Access EFI related tables in the clear > x86: Access device tree in the clear > x86: Do not specify encrypted memory for VGA mapping If the SME encryption key "is created randomly each time a system is booted," data on NVDIMMs won't decrypt properly on the next boot. You need to exclude persistent memory regions (reported in the UEFI memory map as EfiReservedMemoryType with the NV attribute, or as EfiPersistentMemory). Perhaps the SEV feature will allow key export/import that could work for NVDIMMs. --- Robert Elliott, HPE Persistent Memory