From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756597AbcIGOLt (ORCPT ); Wed, 7 Sep 2016 10:11:49 -0400 Received: from mail-bl2nam02on0080.outbound.protection.outlook.com ([104.47.38.80]:52800 "EHLO NAM02-BL2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751081AbcIGOLo (ORCPT ); Wed, 7 Sep 2016 10:11:44 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Lendacky@amd.com; Subject: Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption To: Borislav Petkov References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223646.29880.28794.stgit@tlendack-t1.amdoffice.net> <20160902181447.GA25328@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: <616644bb-6a38-e480-3375-bd39a8487b7d@amd.com> Date: Wed, 7 Sep 2016 09:11:35 -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: <20160902181447.GA25328@nazgul.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: BY2PR21CA0034.namprd21.prod.outlook.com (10.162.74.172) To CY4PR12MB1142.namprd12.prod.outlook.com (10.168.163.150) X-MS-Office365-Filtering-Correlation-Id: 5093b0eb-fe5b-47a0-cb7e-08d3d728e41e X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1142;2:vsR31m1rjIQUeeLI+ohGBMM/Pmpx2o+ISN/ulXVIJF2eOZzLL8DQBpuQ6xg0kA+mz3DtDn6VaeRyefEnbFurllrb5gs9q5LHrBDpU7TnVOhtaHp5FXMFPSz881X0+UIr7wiUN769Mp8csn7FZwnVqd1M+BV97MWZvJ88/zqNAYmvK5wsSpY9gsx/NPq7neBv;3:XUmZa1AXgj6IF7jURrNiS/nm/Mq4FfpFGXzDAsaWcuiLJWhCmRKJbdfi2+TKufu6DevYgG7Wp1KNHd4gHNpJnYxx5p6OWwIZn171Js71A6i3uVcJmUd7p6PRVRETEmPe;25:jTNfJPQEziXSNaMhZ5eUwbS434OGnc9GAmHoKhnldxjaEFSy82iOsT7YQkaRqU8WhKFaqlBbt7ovol99ey1R6tzP/4YGueUAC4TVugP76PEuDS3T2tV79Ih6lIxHvujSqufPCAsTIxhXIdhBFLdu79YNBbbDnEZitQhJHYgYKX7iwjryGQBMqv/UxqXy4rQyd5CZchsnkHpscVK9KgYrVsvhhDMhsg9J68R2OJndXaQzCcFekZI+YEyASp+TQV4QKQY5+PfMjjNw61amp+RALqg4b3PUC/guWkakvapaHDo9MPnbKwpa/8ZJ9DYk9CaHajMW7tfiIugMqlhWddTTc8nlGbqsZjRTNvIAIMCOQp/+dtUZ6SuAPyXwhOUCzKZC7nFrRUuVVtSrB8ZtCUZF0A==;31:1djGokMzZ4BbmzPSsfoVnWTYZbFlT+9FJB6E8ZoXVXNQYGM3nHuiVIVcp/0IBaWMXoHeYEEbRg4CWAjp+uYHjvJFXODV0OJkJXO057lKSga+YzqQBbY/BJ8RItODpwnShlw1ag5d2BA52Kneee6Yr2KgIedZOqVCNq6KloxI5S9ePc6yyDxA/3u9ajaVrI7RiIk1RXba5bVUgpSjPvybmWtfHkuVYA+/MbknVeBD//A= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY4PR12MB1142; X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1142;20:D6ytUR6cXtZeIfaHAhNlst3WUBYzO0TG7O0vqLD80uQtciv6ZPW6vWqwgSkHeT5vv0BdMdfzakOFY1l5+hTyiPiVuUtrkS+sjoGGmPLhSUex0nON8G77YYsqLrhL1m1kP+A5/S+pMLPqIKxQn6++Txm5o5RfKYGMlz377x98+iRXueeT5FeGFZEOiNSDUigRXMJUGEk98zw//4FS2iCnBcYHISNwp1i8c0WOWFj+iZ3Z5ldiDoRFsjPMQ5LOYFmAi686KuEJhZEDLUhHO9pvOvkt1EeQx7+bWNVvdfwwh+wbDCoQkTPqvyqGXOZ58QIMV2qKZ1H0r31UquLeItNz8qWs+jji0oUqQDbfHYsST+VBwXfwbTd9jD05ODRQpWdeE9QRVv8ruOtq3+f0fjDNJaRwfyTETM2UCx3P2YW81f7biSROxKI0hlA5e3GmfX8Pr7aqc9I2tsScxzdztiO2BjY0SGT/sxs5BJT2uu97Rlbv1TH59/LzgyWCiyCnmNj8;4:bulpnMDqs49xVNsy+f9ZOi6zb1xEs+HM+ANqiHqt5+GVJOYPm5I33a5gydEMwRtzAX1coEj1/Z1vWFlDca/X2islolyi+f3Py2MutK8wmwHuhK6n0k4yCsf9mCNmEPnSvxWgUzSTCourho4tzMZJSSHIIWXCr6Djxp/zOCWoDAGVOByRvP4xxZHZeC9Z1VgK3hKtKvvijcQw/ELTkVTT5EdK34EIqabwQPqfKUO8x8ydNbB7b+MOHh0c+gBDqopgt8CCBEVAYK2LgJahCfxC0ZAUmlkQrEYxljla9EveIguCMyED7kNZhUsZCv52dfiHIZIciM0ZrbSrxWyCaxdfFgK1rPvheG/Bjj9tbuDzlt9CzY6EyE1h5cRURJKrvPj89OPqjA33GS1wDS7iT12tjxDL2ZQOgKqVlZfk3HzUCuUYJKoE3A0jYqOKXfyZiMqA X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(767451399110); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);SRVR:CY4PR12MB1142;BCL:0;PCL:0;RULEID:;SRVR:CY4PR12MB1142; X-Forefront-PRVS: 0058ABBBC7 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(24454002)(199003)(189002)(377454003)(31686004)(5660300001)(305945005)(19580395003)(19580405001)(66066001)(65826007)(7416002)(64126003)(36756003)(189998001)(92566002)(83506001)(3846002)(4001350100001)(6116002)(586003)(4326007)(97736004)(110136002)(33646002)(2906002)(54356999)(8676002)(77096005)(105586002)(106356001)(81156014)(101416001)(230700001)(86362001)(7736002)(7846002)(81166006)(42186005)(31696002)(65806001)(65956001)(50466002)(76176999)(2950100001)(23676002)(47776003)(68736007)(50986999)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:CY4PR12MB1142;H:[10.236.18.82];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjEyTUIxMTQyOzIzOkp0TEF2ZTNRZ0pjeHNCQlRCZzhPK3JyMUNN?= =?utf-8?B?K1VQRXFMaWxwYTJpWWxuODgzdVdKK3RvQ21mTEhzTGg2anY5a1BmVFFSb2Rx?= =?utf-8?B?WDkrK2RoV2F4dkRkeEZERFBUMFczL21US1BLYXV3QlhDdFU5MTBuMnAwSUV5?= =?utf-8?B?aU9QRDhtdnAwNzcxTldaa1Zia2tQdzBCNDhyeTA1cCtSMWx2NUVFSFFBRThQ?= =?utf-8?B?RHRFVm15WXM1UlRQSXF6aXBscTM5ZTN1eUwzRkJFbi93YlJEbi9lbktWWmZp?= =?utf-8?B?ODdhWnJyNE9vbGdWODVka3RNdEdYUkJsZjVFZGdPTDZOaWE4R0FpUFhXTjJZ?= =?utf-8?B?dXc0MDJQWnpPMld6YnZuL0dWbDVKU2wrQ3BSOHlKZjI1UHRzTjJxTW9pcXk2?= =?utf-8?B?YlBSZUt1OFdXZlRrMkdJRHNOSXZLNnhJaGp0cEpoenE0K3dtOW54bnhod0Qw?= =?utf-8?B?VXZNMG9icC9TbWZwRi9qaGFhdS9GOG9idDd5UDgrLy94bTBTOHdHalFKNW1w?= =?utf-8?B?YksrVk90Q3FpWGduVkhRVkdSWmVEdWVpOUxKdVBJTTFEYlh1K1hxc0xyUTR5?= =?utf-8?B?dE1Rek5TUUFJcldNOC9vRTNXOEZRSCtnajhQMUsxa2I4RzNZaGdmRHRSSW4z?= =?utf-8?B?S2RrWFUzVURScFp6U2VUUUpwOXR6VngvWFNvMW4vaGZ2SmxtK21JdGFmNy81?= =?utf-8?B?RDRBalc5ajNhdkc1anFua1ZsUG56K01XZXFtSEd2TGFIKzg2M0VtUEZnc2d1?= =?utf-8?B?STBvbnJyWjF5dFpBZGgrMnF0ZTRSczlpM1dWR1pXaFkyWlgvZkVUR3VjNm4y?= =?utf-8?B?cFpjOGxtdy90NzNxbWxYanhtL3lwb1lkMEpFbGVSVWIwUXVWM3FBMmYwTFUx?= =?utf-8?B?eHgvNXJOM2VLRFNUMlUzNjFjdCt5ekt1WEdzTC9hOUlpNGlSR0hsbWpQQllJ?= =?utf-8?B?YXlBSTFNZG4xNXFETTNBQkpwYkwwNXlmekRDT0MxMldSRzdaeUpOZyt4YW5V?= =?utf-8?B?MVpleWQzVXJzdTZuUElxazZzZFFCVjZZSzZ0Q0Z5SkVUUFBSYUxlNG0zLzhj?= =?utf-8?B?TzFvVzhOd2gxOGdMdEQ4emxrVXVWOGlmT1BtWmZ2OXFqbDNBajEvMEE2MEcz?= =?utf-8?B?ZlVHVkp0Kzl5R29PYzNldTVUZjh4NEdlVjFoYktkSnJ5V2JrV0gzMmpIMXRT?= =?utf-8?B?eHBSTTRlYWNSc2M1WGcyUjJaSzNvRENBTVl0ZUJTSEJRdzJBQkxvVkl1aXA0?= =?utf-8?B?YnlyOWpmR3hVSEpFOWFoakV1cEl6WG9POEFLbEFnYTcvbUp2a3B1Kzk4WVdY?= =?utf-8?B?b0RxM21wMjFvRkVYUCtWMFFYU05ITmg1YnMvUndFOUZCbVVrRXowSmRPeUdw?= =?utf-8?B?N2VlT3hMcndnQS9FSWZGZ28wczlweXdsV1MrUFpBdjlSRW9nQ0M3NTNQRHdq?= =?utf-8?B?STc1UWJ1NnJUcndzRkluR3RWcUg3dndGUUxDZ3RXS1dTTzJJbjhvSmdlckVp?= =?utf-8?B?blFkLzdLZjNJdWR5c1RaVzVWTTl3dmVyc0JNUlp3djc4NzdkSURvWCtBUEdO?= =?utf-8?B?dHVJeHRaTjNwbk9NWFlRdVdmOEp4ZFhHcmpXanZkWjkwYkE2OUgrSEFsNisw?= =?utf-8?B?c2NkUTRzYmNyQ1N0MmNLdjNhRWZML2tUVjlZYlp0dytCVHI5Z2dFNGZBcExk?= =?utf-8?B?ZXFrVU9ONUJoSHRPWkMydmZTcWNoQ2tDcVNNYi9MekZvVEpUQ3JidTdxcWti?= =?utf-8?B?ZFRJUGhhTUJEY1VBRXladUp5WExzclBLRXVPL0luV3hJZWtnQk02N1NMc1N0?= =?utf-8?Q?0b/e/FRrefKLh?= X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1142;6:+xJOiiPwmBMao14bezEvTsMOWY+hvwcnLyWI6KeUd/idqw9w3XhMtDKXmkFpEw68pdhUJ8ytNATqimc5GodNvkkLexsrbaeqaAUJYdD9vX2lndjYtOmfxDfH3xWHZnV2TVXJvrwnBG6fcb3XaBx5h+vgMkZI6KTv3UbB2bM1p4fWYLi/7jzYQKfc7eaYmaCR5Q4nr+RWvTkaao8SUh0csOlYgdHoPGFh/xoAJeYWHVO5C+W+923EPgGpcm5Gg9sLcXZDPaweYxBbHsweB+lYAfj9/aFfnekWjObbfpWTOzL+Kuh8NPkkYmFqwfuk9K0w6UtduTqA38i2Zk2BchsqGw==;5:roOfFurvHH7vTgGuZaOkuQYcMvBdXLomKUq9QTm5BvbAj7O/2p41LhMtzqxYZWcyIWts8efTYRd1KXHiMs2u/yxDcRoB0K3OaHxKutTd4SyRvXlBFZfD1DRMjJeNj06Q9GrbOs6PfsOevDmMad5lDA==;24:aH0CNr2WR0KfKSt6IrdmGyfFtK7JMeby62qphzK860i3BRHOdQJasgtXdSPeWUyqBnnOQm96XWzRSSJeWq8HfX6qvhK3k+f0BvwAr+QlNDo=;7:YICUV0mfN66ZzMBS3tJ7zhIaKIa+hGDo3wHcSxpYMFfmr0CwPsCI5xLqOBT08+wu7V0kMr9HHvqKasPzH6G2b8e/SFmk5SX2E+j6reuNUTnSKZqi0Dp4Hno8QYigromVo8OPeRvSh4oFBcWTIpp85Rn0dEP6IbERkEISP39Th7cJDn/6z9oLVSWklpWZGHHpNcFTQu+sGYnk0huxDReEwlzP2milr++68lREwIhijmyK8d97OxGybyAiwslElRry SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1142;20:0zBynZdP2JqFSvIYKPMQER//NOyWzXn/Am/OwtaAQqRPD4xLjDL1zv33zvYa3etcG1sps0+njRhQee7XbrHJ1+t3z0YmdrfVE7fTeiEarzLh4yaqHHVLzAD/4VjI5HSu++DPmhibSL3mkEmAwHUlVrIe7FDtY18lQyWnOY0xETNcetEHmkVFv9sChY9L+MGyhqIsbxF1cyWfFTbRCumwbl80WOYfawt16nF1IpYpoWAEGXuPWgLB/fJSia1ZSUCl X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2016 14:11:39.3891 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1142 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/02/2016 01:14 PM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: >> Adding general kernel support for memory encryption includes: >> - Modify and create some page table macros to include the Secure Memory >> Encryption (SME) memory encryption mask >> - Update kernel boot support to call an SME routine that checks for and >> sets the SME capability (the SME routine will grow later and for now >> is just a stub routine) >> - Update kernel boot support to call an SME routine that encrypts the >> kernel (the SME routine will grow later and for now is just a stub >> routine) >> - Provide an SME initialization routine to update the protection map with >> the memory encryption mask so that it is used by default >> >> Signed-off-by: Tom Lendacky >> --- > > ... > >> diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h >> index 747fc52..9f3e762 100644 >> --- a/arch/x86/include/asm/mem_encrypt.h >> +++ b/arch/x86/include/asm/mem_encrypt.h >> @@ -15,12 +15,21 @@ >> >> #ifndef __ASSEMBLY__ >> >> +#include >> + >> #ifdef CONFIG_AMD_MEM_ENCRYPT >> >> extern unsigned long sme_me_mask; >> >> u8 sme_get_me_loss(void); >> >> +void __init sme_early_init(void); >> + >> +#define __sme_pa(x) (__pa((x)) | sme_me_mask) >> +#define __sme_pa_nodebug(x) (__pa_nodebug((x)) | sme_me_mask) >> + >> +#define __sme_va(x) (__va((x) & ~sme_me_mask)) > > So I'm wondering: why not push the masking off of the SME mask into the > __va() macro instead of defining a specific __sme_va() one? > > I mean, do you even see cases where __va() would need to have to > sme_mask left in the virtual address? > > Because if not, you could mask it out in __va() so that all __va() users > get the "clean" va, without the enc bits. That's a good point, yes, it could go in __va(). I'll make that change. > > Hmmm. > > Btw, this patch is huuuge. It would be nice if you could split it, if > possible... Ok, I'll look at how to make this a bit more manageable. Thanks, Tom > > Thanks. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Lendacky Subject: Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption Date: Wed, 7 Sep 2016 09:11:35 -0500 Message-ID: <616644bb-6a38-e480-3375-bd39a8487b7d@amd.com> References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223646.29880.28794.stgit@tlendack-t1.amdoffice.net> <20160902181447.GA25328@nazgul.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160902181447.GA25328@nazgul.tnic> Sender: owner-linux-mm@kvack.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 , Dmitry Vyukov List-Id: linux-efi@vger.kernel.org On 09/02/2016 01:14 PM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: >> Adding general kernel support for memory encryption includes: >> - Modify and create some page table macros to include the Secure Memory >> Encryption (SME) memory encryption mask >> - Update kernel boot support to call an SME routine that checks for and >> sets the SME capability (the SME routine will grow later and for now >> is just a stub routine) >> - Update kernel boot support to call an SME routine that encrypts the >> kernel (the SME routine will grow later and for now is just a stub >> routine) >> - Provide an SME initialization routine to update the protection map with >> the memory encryption mask so that it is used by default >> >> Signed-off-by: Tom Lendacky >> --- > > ... > >> diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h >> index 747fc52..9f3e762 100644 >> --- a/arch/x86/include/asm/mem_encrypt.h >> +++ b/arch/x86/include/asm/mem_encrypt.h >> @@ -15,12 +15,21 @@ >> >> #ifndef __ASSEMBLY__ >> >> +#include >> + >> #ifdef CONFIG_AMD_MEM_ENCRYPT >> >> extern unsigned long sme_me_mask; >> >> u8 sme_get_me_loss(void); >> >> +void __init sme_early_init(void); >> + >> +#define __sme_pa(x) (__pa((x)) | sme_me_mask) >> +#define __sme_pa_nodebug(x) (__pa_nodebug((x)) | sme_me_mask) >> + >> +#define __sme_va(x) (__va((x) & ~sme_me_mask)) > > So I'm wondering: why not push the masking off of the SME mask into the > __va() macro instead of defining a specific __sme_va() one? > > I mean, do you even see cases where __va() would need to have to > sme_mask left in the virtual address? > > Because if not, you could mask it out in __va() so that all __va() users > get the "clean" va, without the enc bits. That's a good point, yes, it could go in __va(). I'll make that change. > > Hmmm. > > Btw, this patch is huuuge. It would be nice if you could split it, if > possible... Ok, I'll look at how to make this a bit more manageable. Thanks, Tom > > Thanks. > -- 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