From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757348AbcIGODE (ORCPT ); Wed, 7 Sep 2016 10:03:04 -0400 Received: from mail-sn1nam02on0085.outbound.protection.outlook.com ([104.47.36.85]:61616 "EHLO NAM02-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753998AbcIGODA (ORCPT ); Wed, 7 Sep 2016 10:03:00 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Lendacky@amd.com; Subject: Re: [RFC PATCH v2 01/20] x86: Documentation for AMD Secure Memory Encryption (SME) To: Borislav Petkov References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223539.29880.96739.stgit@tlendack-t1.amdoffice.net> <20160902085045.GG17338@nazgul.tnic> CC: , , , , , , , , , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , Andrey Ryabinin , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Paolo Bonzini , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov From: Tom Lendacky Message-ID: <3fbb0763-5f9f-6ff7-2266-7478fb12642e@amd.com> Date: Wed, 7 Sep 2016 09:02:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160902085045.GG17338@nazgul.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: YTXPR01CA0012.CANPRD01.PROD.OUTLOOK.COM (10.165.183.150) To MWHPR12MB1151.namprd12.prod.outlook.com (10.169.204.15) X-MS-Office365-Filtering-Correlation-Id: e3199767-2bec-4217-0161-08d3d727a867 X-Microsoft-Exchange-Diagnostics: 1;MWHPR12MB1151;2:iU+IewbNjsjdN9DyVfsoj9fLb6Wm9zgwiEYuqXxmloVkEFjyNn86TkYRLna3dapCpAN6wan6zy5ScuIveuWlxADqtLO0u1jiFwxl/JYzDkQI4llmbhWJXrXoBG/ePSWR1BeLs5+ct6bnBM72ZXOKIuXQDwMGrLigB6yfH8OhyRAtnGF6IsHcTNT985taFaat;3:M+BwZPUoZpvIObajTOSSmDvdO8yjvm3v+uEaoa/Gcj9LxZvsoPIA1iYTol7OwDDWbqirXBIcfRDFcHzzuU1K7e02fwsG2Goed9E6iS6a9HK5AInyYizthr2SmUPSquJ4 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR12MB1151; X-Microsoft-Exchange-Diagnostics: 1;MWHPR12MB1151;25:rQtjYmsE0PHcCydGU5vWMCmhHLnzN3/+EvgVtP96iqVhazpBPoCxDuNiBnCqW7uFm2NSYm6l+dsG+GLyfslme6+Hrr6rEx3SMb8WJLe4HreUMZFkooaZLbNBCV93yhpmQz42fsX+XCUsiIQ7BGHkGeFpA0TVFpaI03EOLgcvCmJ3T0mKoEhNwujrctHPrIQ8AMj8lSp1dqBOp7i4ccWiQrvwUoERNgcy2K7oJUZndLSnatsVAwMUvUjQoBhiAonCmammit2W5G6DyrW5ZMIeWkwnL9o+HxszRmZsRQq4uk+DkNQcatV+pnCgncQA23l9p+pstzl0nTwJn3K6xhGD337YPL4K+9AGJ34D+V9Y+HHnM/oCaz4/ZpzkSHxjH/4MJ8zfCp3ssgrL1fG7YPatnDu8aZElm9z6BiFdZri/pqNyOfugzK1PW6ZIdcHl/SM00I4VBL6c49VeEEWOeGPha+44dvLXYUU5MWQu5txaV5wtEu5TS81acMhUFd2IGxHnF0H7cq8NJHVyRkyhgnvplZ3kDi6LcFyN1KOo17JC5H70YZOIIde45fE4vxyq+db3F1CxwLQdd9Bk00tDujXeMf55B6dUZ7qQ3GLhoaQ2gQFpFTu62jTj+e4Pvri5EVluu9Xww2a12Ko1fizFKnfu+nrZO/HPwqR7Mt4bQTYAp9mKoREz33GoJygpS8UeBKto4F0zmLtN5Szad5iuHkF2uktYHiYLdIldVfX+AaTDBXmxldNsneVccKa2oLJeNeOQ X-Microsoft-Exchange-Diagnostics: 1;MWHPR12MB1151;31:3JL4ljzB3avAmy7XnKwdWjjJofHSHu6zZs1BnB3Br/VOR3iEg9yy69dhgDxwotqRFRQ1Sl/IWXTFzVBO2rpdrTFelRT/ZySya1dvwTc4RroIB13WyzyRoJr7RJuAbvjfSZDIlJ54grS2Fqn4I4Sg6hKuuogZOSfAVnFNn6Lg0lVY3IUfQmv+UF5PS60YXG4ahmK/n8BmWM+fIe4ENrpjrIbl8A5luLSxnu3vOfxYCTs=;20:9orI+ykCIxRjJ3rK7dgMLQ/gilPK0KUugWer8hf5KGfBZtGT9bXENDXcTMio0/UqS8LHePg7g96PADGmhTXzbvzViMjpNZOeHoNtxJ/JI6ue2DIoYbq0xXX/xXUhdXVFMdK+WxZZW4AgAQGOB0VGIdTFKFIe8xx4GP3xsNN1VNI2Nx011EphCyPZvf1OYI8v/RZSuxWK+HgzBTYcBC9AtJTQq7+G1rvrvk/vb/ttqQ3nAIUlkau3ZlQejDLB+9PlAGHvb/acAE7JhnzaYD+plpx+pCzTX5wng1gYaRcKZX+gyhexpm+O4uE9b9hTSW9zl64Wosoz/SrnRhWsxw8KotvkwwE3U2jEk3BeJJIK1N9GyP1X36cOPNoPsICz/f37DGXF+UdQU+P9+M24FxT6isastQQmv4lUxi0FlN71rW2LC1w20NnwnXhSS396nM8p9M9qyZ8dRLRrDWMfLYNu3owezVeqbQQnDBjnYSxcHtSJhuhl96TAmFzeiPISAt5E X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(20558992708506)(767451399110); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);SRVR:MWHPR12MB1151;BCL:0;PCL:0;RULEID:;SRVR:MWHPR12MB1151; X-Microsoft-Exchange-Diagnostics: 1;MWHPR12MB1151;4:aX4/6Lg25RvzzmH6/2FnQsVvfFrahwmLLH0yAJSZW9PAvpjRyA+tul0qPldwCJ8hUR+PHXFtuJYDCG/MLlmS8yfZ+A0IcTvVcbiQcr0PboIcRquqJF/BTXrPOCS95oiIC1LkF9T78FB4b5g/PZH514BXwCI9ubXa2veXRaw13j8DmeaZ6pVkQskP/9fR1TYgDZKMRQOydZOY03W2NNTIxnlQNqsFUEwA1rXIasrvZoFV6QLsVPNiF0gjVMMzN9LzTujK5Bm/wuOSp4R7KY2/NSQbN4mA+SShOVRPt7tzoKizpWmBBUo3937OzneLZR80+27JpfB9gc9hUYHYEi8ZNskyCoHvm4PegjBIbCymY9UEjrnCaAdTePiArgNB/I2kCNLx1bg34CBvEg2h8jzM9Ni/H4LoN6mPnjDyfHSI3GB2wCgkI0Thb+LZrcW15rbSBwfHn34MSx92UCn8zYfnL7hjOFE/sPlrPZ/dP7alVVw= X-Forefront-PRVS: 0058ABBBC7 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(189002)(199003)(377454003)(24454002)(36756003)(8676002)(105586002)(189998001)(106356001)(83506001)(81156014)(81166006)(230700001)(586003)(5660300001)(65826007)(19580395003)(7416002)(2906002)(68736007)(3846002)(7736002)(110136002)(92566002)(305945005)(4326007)(19580405001)(6116002)(97736004)(4001350100001)(23676002)(64126003)(66066001)(47776003)(65806001)(77096005)(31686004)(86362001)(7846002)(2950100001)(65956001)(42186005)(76176999)(54356999)(31696002)(50466002)(101416001)(50986999)(33646002)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:MWHPR12MB1151;H:[10.236.18.82];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjEyTUIxMTUxOzIzOlNyeFZ4WHhBUHZYZ1BaZ2dYNFRTTFJua2ZH?= =?utf-8?B?dUR6dGJRS1JQREZkMmV0Z3JHVHV1ajJDbzE2dVRNREplV2pzSUJOa2piODRU?= =?utf-8?B?cDJjeldMWk4waVoxZDh6TnRjcmt6aG80U0lSQk1XSFJlNEJMRU5BTFNIM05D?= =?utf-8?B?QWdQT0pneit5c2RtUXJrSWhlTVgxY3FENGw1NWhLK1VzYTR4ZkVPMklSNFEx?= =?utf-8?B?a2lEenVQUk5iTVRUbndEWDJJUFQwWHpQUlRHOWRsT29YOUhhSE5QYjd6Y1dq?= =?utf-8?B?UHV5VmV2Z3dYOGxCWm11TVNWV2RXcUI5eVZMSS82K1pZNzVvNFVFMWlFN2NR?= =?utf-8?B?OVFBTWwxYnh6RFdKNXpHTktsekVhNnd1aW13WVl6TG9qZ3dUMk9FWWZ6eE81?= =?utf-8?B?bWR2cjZBMHZUaFliWld4K0xicDY2cTVTdVVqRE12cnhTcy92RUtvL2VvSElP?= =?utf-8?B?TXhMbnhUVHB0dHRhN0VaM0h6N3pxSWlud0RCbHh5Y3dibXVTSGZDZWxKYVdy?= =?utf-8?B?UTZkR0xYK2E3d2VkbGh3SUVIOXlKRXlKTXVlRzdhS2lGcFRRQm5XQWN0bkd2?= =?utf-8?B?dGdHTkNycEtxUHBvRnRDMlpJcm91dit0Y05SYmJaU1lwTjBWcGUxNENqelV2?= =?utf-8?B?dFVhWk95OW1VMGZndHRPT2lxZVlBZ1NBM3FvbGNpUHJyQy9FaXFGUnBTTUNn?= =?utf-8?B?MnlSNGhUR25qdnFxb3BMWmxBVGZvTlhOTmVWTko1TlFPYk12MDU1cU9YdDhP?= =?utf-8?B?VEtPbFdPejk4Mk1iRTQzblFMS0Fob3lKY3h4aHh1b0s0TzFteUs2V1FEQUpN?= =?utf-8?B?b2pSMDBkL0hLMjJuMm5vRWNCMWJ1V2lnclJSWWg5NGdOVzB6cm5aall2Wksz?= =?utf-8?B?Y0NlZU5YL0JOdVZqTE1BZjA5VUJHZjllVHBJUHRyZ2k0T1didC9JeWZsU0J5?= =?utf-8?B?V01WRUtxeWV2UG9mcHJWeVY4amlTdG9YeXRlQXBEZkFxUjdJalVzbk0zd3RG?= =?utf-8?B?VWVod0VHc2RrRUhtWC9ibDIrR2ZKV0RQRjVYSEVNc0ZoVVY2czhDZjcwclpI?= =?utf-8?B?Y3hUc3ZLMmVYdzhxZ2VwVmk5TWsrZlB3cmQ5R2M0ZmJLS0dYOFZHQ1d0L3dk?= =?utf-8?B?Z01HWW5WbFhaUHV0TTBVYWZudW0zdEpJRW94SWFqcE81RUtoOGlsY1pySWg0?= =?utf-8?B?UTU5aGFtNDFwYlNIcmtkY1dvT1RDQWRNZ0FpUGNsVVZ3bWs3ZnJXakZDeHJx?= =?utf-8?B?ZXdQRWprdGU3aTR3OWExWEtoTmxlRU1UcTVHOFE0M3RqQThiK3cwelV4VjlE?= =?utf-8?B?dm5vaUVuVUtvM0J5ZVpXVkprRWZnN1o1UURiY3p2TVMwMFNud0toc3FDSlcw?= =?utf-8?B?cFhsUnJiZThzbXJFcFRSeVZTc055akp5OFpNaTExTlBCcWVoVDlCdytSNVdZ?= =?utf-8?B?eml0dzlSekQwVDhFMDc2Z1pJcWwrQzZHRlZYbHV4NzVqWjAxYXpKT3E3MldG?= =?utf-8?B?QUloSW9GMnNXaGZLSEZBQml0a29uSGhud1hJUmF1blF6dTVkUlFYejRXK2pG?= =?utf-8?B?ZEVDY2tZRkFYeGZtZ1JzVXh1ejg5NkZyWjVJRE4wejloeWVxd3g4R0t1R2FP?= =?utf-8?B?dkVXQmd5aUVoajlQaE83V0hVZFhqUG9MSkVUMDNsejhhRTIwem9DRm1LQ3gx?= =?utf-8?B?dTlWckE2Q0Jzc0JBVDdscmRLR2Zxa21IVGNzd25QVHUvY20rTmk4Y3BwWjM2?= =?utf-8?B?UUltSXpVd3gvTS9ZalUrb2s5UmwyblJLYWJQaUwzQW9hK3hyT2lCQzREVENq?= =?utf-8?Q?JU984QXRUHadz?= X-Microsoft-Exchange-Diagnostics: 1;MWHPR12MB1151;6:uTXCMyFYIzZ9cqgbl7Kt7TMM4QW0PwSsLuJ9hpmx/pQ6gACu8CnVDdMhUFFCne1imSLngEkNWhe4IYoAR7LtsazYelbFRwsXv7jP1v2wy1pHTpsq9riOKvFsuke/EVdzZrmcce85Yo0UbqdbZFhfGXD2SxQJ7zAcJPUARG+19w2VZ6GNhivV2cp2KfRwz9IhScQOvUlbFlBWLqP5Y1l2iF/loBKv5KqtfPtoHBCwwSE/939HaU1m4azMprvIglKBXrK3bs3+JwZBdhNm1JFyEnSZMWUrjOnVfACKY/LQjQsEx2ONO8ULvdyKskMXmmbaCi8BvqJRo/UwxXGLGeNY0Q==;5:p2epAtGS2yDPzNO21y5p8V7M1YRNJWLBHTuzN8fg35f7NswRT0EZobpewngzJc2SzT62qeHOpv1MRSrKUpNKtZz4uKFVNcev5LhhbzYzTzOLlcpoYmT8R43PDzcC2iAiXd5chd1uXh3D46U5INAVrA==;24:XcZPfBp3Plf7HuRTPfBoRJDa/YoAKgL/tEnWKqnMXi2P+FYVXml636D3p6+RvHBhNhUNptYwFMt+ETscdQTPTxPHGVFTT3HreIGjzQRWstQ=;7:YLWVW2N3lMuLBtBhQIVx29r5Mh/pN1MX11N81qNaNPU7v3Zwo3hd4+tg2MKo+Ec5C3rQYTUOr3nBQ6HlOvAVvoQTdgP+y9M7OzXMQEw7h/TPJhP0avLRtU8/XZJgllHKhjVBHfgL8hJU5MF2P3pUFcEv7F/ZW0W4iIISzn+ppesir3HdsNZCrbX+c8GBfXxIEIukGleh+iCJIN8d0hKJDwYUoY+Jire4ZkrW6ohV0/ciIgTfaP7VDKFDJAMyy4eb SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;MWHPR12MB1151;20:AsfW4IEovkbuR9s/eS2VrmKyQIUz15tUMTZhMZjtctS2rVJcwPAa2/ApoVlpZ0Dd2g1g0ut9KJJOkpDf6723V9NevzPIeretqNiyQnYfNkk3cMsc2KhKz6h/BN+L2NkO4ysxEn/IgWEcbKl7/wVrI6WIEF9iamGThHo9sOy0LjexS2c+RMeOShA46lOB/gpCW5eZ8msJVDio9mBSfLK3/047rW1NSVeRA5Gpvp+ULiSzKsZKZ7+sOfRve4QKxon3 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2016 14:02:48.9035 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR12MB1151 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/02/2016 03:50 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:35:39PM -0500, Tom Lendacky wrote: >> This patch adds a Documenation entry to decribe the AMD Secure Memory >> Encryption (SME) feature. >> >> Signed-off-by: Tom Lendacky >> --- >> Documentation/x86/amd-memory-encryption.txt | 35 +++++++++++++++++++++++++++ >> 1 file changed, 35 insertions(+) >> create mode 100644 Documentation/x86/amd-memory-encryption.txt >> >> diff --git a/Documentation/x86/amd-memory-encryption.txt b/Documentation/x86/amd-memory-encryption.txt >> new file mode 100644 >> index 0000000..f19c555 >> --- /dev/null >> +++ b/Documentation/x86/amd-memory-encryption.txt >> @@ -0,0 +1,35 @@ >> +Secure Memory Encryption (SME) is a feature found on AMD processors. >> + >> +SME provides the ability to mark individual pages of memory as encrypted using >> +the standard x86 page tables. A page that is marked encrpyted will be > > s/encrpyted/encrypted/ Ugh.. I thought I caught all of these. Obviously not. I'll go through all the patches on this. > >> +automatically decrypted when read from DRAM and encrypted when written to >> +DRAM. SME can therefore be used to protect the contents of DRAM from physical >> +attacks on the system. >> + >> +Support for SME can be determined through the CPUID instruction. The CPUID >> +function 0x8000001f reports information related to SME: >> + >> + 0x8000001f[eax]: >> + Bit[0] indicates support for SME >> + 0x8000001f[ebx]: >> + Bit[5:0] pagetable bit number used to enable memory encryption >> + Bit[11:6] reduction in physical address space, in bits, when >> + memory encryption is enabled (this only affects system >> + physical addresses, not guest physical addresses) >> + >> +If support for SME is present, MSR 0xc00100010 (SYS_CFG) can be used to >> +determine if SME is enabled and/or to enable memory encryption: >> + >> + 0xc0010010: >> + Bit[23] 0 = memory encryption features are disabled >> + 1 = memory encryption features are enabled >> + >> +Linux relies on BIOS to set this bit if BIOS has determined that the reduction >> +in the physical address space as a result of enabling memory encryption (see >> +CPUID information above) will not conflict with the address space resource >> +requirements for the system. If this bit is not set upon Linux startup then >> +Linux itself will not set it and memory encryption will not be possible. >> + >> +SME support is configurable in the kernel through the AMD_MEM_ENCRYPT config >> +option. > > " ... is configurable through CONFIG_AMD_MEM_ENCRYPT." Ok. > >> Additionally, the mem_encrypt=on command line parameter is required >> +to activate memory encryption. > > I think you want to rewrite the logic here to say that people should use > the BIOS option and if none is present for whatever reason, resort to > the alternative "mem_encrypt=on" kernel command line option, no? Yes, I'll work on rewording this section. Thanks, Tom > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Lendacky Subject: Re: [RFC PATCH v2 01/20] x86: Documentation for AMD Secure Memory Encryption (SME) Date: Wed, 7 Sep 2016 09:02:38 -0500 Message-ID: <3fbb0763-5f9f-6ff7-2266-7478fb12642e@amd.com> References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223539.29880.96739.stgit@tlendack-t1.amdoffice.net> <20160902085045.GG17338@nazgul.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160902085045.GG17338@nazgul.tnic> Sender: linux-doc-owner@vger.kernel.org To: Borislav Petkov Cc: 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, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , Andrey Ryabinin , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Paolo Bonzini , Alexander Potapenko , Thomas Gleixner , Dm List-Id: linux-efi@vger.kernel.org On 09/02/2016 03:50 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:35:39PM -0500, Tom Lendacky wrote: >> This patch adds a Documenation entry to decribe the AMD Secure Memory >> Encryption (SME) feature. >> >> Signed-off-by: Tom Lendacky >> --- >> Documentation/x86/amd-memory-encryption.txt | 35 +++++++++++++++++++++++++++ >> 1 file changed, 35 insertions(+) >> create mode 100644 Documentation/x86/amd-memory-encryption.txt >> >> diff --git a/Documentation/x86/amd-memory-encryption.txt b/Documentation/x86/amd-memory-encryption.txt >> new file mode 100644 >> index 0000000..f19c555 >> --- /dev/null >> +++ b/Documentation/x86/amd-memory-encryption.txt >> @@ -0,0 +1,35 @@ >> +Secure Memory Encryption (SME) is a feature found on AMD processors. >> + >> +SME provides the ability to mark individual pages of memory as encrypted using >> +the standard x86 page tables. A page that is marked encrpyted will be > > s/encrpyted/encrypted/ Ugh.. I thought I caught all of these. Obviously not. I'll go through all the patches on this. > >> +automatically decrypted when read from DRAM and encrypted when written to >> +DRAM. SME can therefore be used to protect the contents of DRAM from physical >> +attacks on the system. >> + >> +Support for SME can be determined through the CPUID instruction. The CPUID >> +function 0x8000001f reports information related to SME: >> + >> + 0x8000001f[eax]: >> + Bit[0] indicates support for SME >> + 0x8000001f[ebx]: >> + Bit[5:0] pagetable bit number used to enable memory encryption >> + Bit[11:6] reduction in physical address space, in bits, when >> + memory encryption is enabled (this only affects system >> + physical addresses, not guest physical addresses) >> + >> +If support for SME is present, MSR 0xc00100010 (SYS_CFG) can be used to >> +determine if SME is enabled and/or to enable memory encryption: >> + >> + 0xc0010010: >> + Bit[23] 0 = memory encryption features are disabled >> + 1 = memory encryption features are enabled >> + >> +Linux relies on BIOS to set this bit if BIOS has determined that the reduction >> +in the physical address space as a result of enabling memory encryption (see >> +CPUID information above) will not conflict with the address space resource >> +requirements for the system. If this bit is not set upon Linux startup then >> +Linux itself will not set it and memory encryption will not be possible. >> + >> +SME support is configurable in the kernel through the AMD_MEM_ENCRYPT config >> +option. > > " ... is configurable through CONFIG_AMD_MEM_ENCRYPT." Ok. > >> Additionally, the mem_encrypt=on command line parameter is required >> +to activate memory encryption. > > I think you want to rewrite the logic here to say that people should use > the BIOS option and if none is present for whatever reason, resort to > the alternative "mem_encrypt=on" kernel command line option, no? Yes, I'll work on rewording this section. Thanks, Tom > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f70.google.com (mail-it0-f70.google.com [209.85.214.70]) by kanga.kvack.org (Postfix) with ESMTP id C31956B0038 for ; Wed, 7 Sep 2016 10:02:59 -0400 (EDT) Received: by mail-it0-f70.google.com with SMTP id i184so34802671itf.1 for ; Wed, 07 Sep 2016 07:02:59 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0073.outbound.protection.outlook.com. [104.47.36.73]) by mx.google.com with ESMTPS id r11si32570543oih.192.2016.09.07.07.02.58 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 07 Sep 2016 07:02:58 -0700 (PDT) Subject: Re: [RFC PATCH v2 01/20] x86: Documentation for AMD Secure Memory Encryption (SME) References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223539.29880.96739.stgit@tlendack-t1.amdoffice.net> <20160902085045.GG17338@nazgul.tnic> From: Tom Lendacky Message-ID: <3fbb0763-5f9f-6ff7-2266-7478fb12642e@amd.com> Date: Wed, 7 Sep 2016 09:02:38 -0500 MIME-Version: 1.0 In-Reply-To: <20160902085045.GG17338@nazgul.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Borislav Petkov Cc: 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, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , Andrey Ryabinin , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Paolo Bonzini , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov On 09/02/2016 03:50 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:35:39PM -0500, Tom Lendacky wrote: >> This patch adds a Documenation entry to decribe the AMD Secure Memory >> Encryption (SME) feature. >> >> Signed-off-by: Tom Lendacky >> --- >> Documentation/x86/amd-memory-encryption.txt | 35 +++++++++++++++++++++++++++ >> 1 file changed, 35 insertions(+) >> create mode 100644 Documentation/x86/amd-memory-encryption.txt >> >> diff --git a/Documentation/x86/amd-memory-encryption.txt b/Documentation/x86/amd-memory-encryption.txt >> new file mode 100644 >> index 0000000..f19c555 >> --- /dev/null >> +++ b/Documentation/x86/amd-memory-encryption.txt >> @@ -0,0 +1,35 @@ >> +Secure Memory Encryption (SME) is a feature found on AMD processors. >> + >> +SME provides the ability to mark individual pages of memory as encrypted using >> +the standard x86 page tables. A page that is marked encrpyted will be > > s/encrpyted/encrypted/ Ugh.. I thought I caught all of these. Obviously not. I'll go through all the patches on this. > >> +automatically decrypted when read from DRAM and encrypted when written to >> +DRAM. SME can therefore be used to protect the contents of DRAM from physical >> +attacks on the system. >> + >> +Support for SME can be determined through the CPUID instruction. The CPUID >> +function 0x8000001f reports information related to SME: >> + >> + 0x8000001f[eax]: >> + Bit[0] indicates support for SME >> + 0x8000001f[ebx]: >> + Bit[5:0] pagetable bit number used to enable memory encryption >> + Bit[11:6] reduction in physical address space, in bits, when >> + memory encryption is enabled (this only affects system >> + physical addresses, not guest physical addresses) >> + >> +If support for SME is present, MSR 0xc00100010 (SYS_CFG) can be used to >> +determine if SME is enabled and/or to enable memory encryption: >> + >> + 0xc0010010: >> + Bit[23] 0 = memory encryption features are disabled >> + 1 = memory encryption features are enabled >> + >> +Linux relies on BIOS to set this bit if BIOS has determined that the reduction >> +in the physical address space as a result of enabling memory encryption (see >> +CPUID information above) will not conflict with the address space resource >> +requirements for the system. If this bit is not set upon Linux startup then >> +Linux itself will not set it and memory encryption will not be possible. >> + >> +SME support is configurable in the kernel through the AMD_MEM_ENCRYPT config >> +option. > > " ... is configurable through CONFIG_AMD_MEM_ENCRYPT." Ok. > >> Additionally, the mem_encrypt=on command line parameter is required >> +to activate memory encryption. > > I think you want to rewrite the logic here to say that people should use > the BIOS option and if none is present for whatever reason, resort to > the alternative "mem_encrypt=on" kernel command line option, no? Yes, I'll work on rewording this section. Thanks, Tom > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org