From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752524AbcIORId (ORCPT ); Thu, 15 Sep 2016 13:08:33 -0400 Received: from mail-dm3nam03on0056.outbound.protection.outlook.com ([104.47.41.56]:38752 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752161AbcIORIV (ORCPT ); Thu, 15 Sep 2016 13:08:21 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Lendacky@amd.com; Subject: Re: [RFC PATCH v2 19/20] x86: Access the setup data through debugfs un-encrypted To: Borislav Petkov References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223859.29880.60652.stgit@tlendack-t1.amdoffice.net> <20160912165944.rpqbwxz2biathnt3@pd.tnic> <4a357b9b-7d53-5bd6-81db-9d8cc63a6c72@amd.com> <20160914145101.GB9295@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: Date: Thu, 15 Sep 2016 12:08:04 -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: <20160914145101.GB9295@nazgul.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: BLUPR0301CA0038.namprd03.prod.outlook.com (10.162.113.176) To BN6PR12MB1137.namprd12.prod.outlook.com (10.168.226.139) X-MS-Office365-Filtering-Correlation-Id: b2aa49f1-b8bb-4855-2b75-08d3dd8adf1d X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1137;2:ueqsXzUwvmZEPjyRZ7W+cGhcWikdSdqmgVtV1iY+YVZfZDh1XPuhtdi1joEAAhtQuiKYdvDutN6GBHOd8C9MgFljmwvgbQdYfDbFjKHIEydhr34wL2BJkmH3ptLFm9m0KokNPSYCCt9vhIHXwt0Gvr6hRZuY1OcmAeOcPsCHsVCqknQRnM8toskHncMWMNCi;3:qMMRUcWBjh0jhsKA+jxdBRCyEPczQNbx4Zbgwp5G+yONnNofcWooh3ryqExJP0o/32+OhE4BNBZrZz0zV/2mPF1P8+V/vxTw+OcGX8qgJsZWiMJG5IwXAf+mAMGLi5Uu X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR12MB1137; X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1137;25:QjC66A7Y1PPUp9ykt2dBitFDwtqoGftnxkphxCMjKxntekeLfSwtKv5mfCyyqX5NqFddY9TOP91mroPDthq/xXYGqe7eFV3T/JJyFz1ElkuHPagigkj1N6WgrKBgpI7wutwgk0y+wzxa3rX0jKMfy3txm/sEdeKEN8lO2KskJSDfjzFpLX7Phn2Ed5sK6C2EFAb37A9yDUAZeutFiBD0j77StcNUhcB6YmTKqpo/LRVRQAwtdqb7Z7Qs+xk2F4qFoy4Ts08o9jHkTnBdlmHgm+ioezKJuOLdHDslt+rqVhfwjWjKhp+2EiNp2fEiCrtq3QslbH3HOsnyKZ24ErzLT1aKd188ymP+exzg9J7SyJXWuiU1NWBOL8HbI8xb7gXpcVQ00cnDNUYzPxp3xaQqLvlzTB4qqeD3nGM//v3plJeu4FFjYhasF06LbeN/rIjZceMw0oIrc93+cuHxoIYO/D1bBuOBZ0sKdKJwt7WFOlA+VJ6WEuC4fxmD7bT7rJltdmoxh3SqqYl7T6YAm7mfgUrgXt7P7vZR4u1Ri8TNxNn3YZTN2ocbyrwVg8M/epIENKP5GP4VdbFsnn4TfuyGR/3OwIkj/AYzjHti4CtVqQzr345InfcSpEOtkRCl4eWnpVeMwp3rnQUqBtAvXJ+YhQZyfxmme6G4cj6gsUG1eh3sWO5nscv6ZfJqPbtTKoRghhvqy2AWosjSMGYJIQtoaje/+lvBvUXH+85c6qHErR93z4z/CWfmrw1NtPJ2765mw7TpEt3QDEEAsc0DWlqNnApOg+7BM2KZJbovkIube98= X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1137;31:Ca2t6DWEYUd5+ACGSSzE8QoejALkVbjN4UeYRKgXVYdjcRO6L6W1Lh9CAOXoMJ1TaV9iwP2RT0F9OEcb6qD2tLPD5yg0Yjc0qvkoEHN8dDCwnsR02MMbI75YhYlhz2kw0mGoH00M5ed+8TLcKdNhn3kDL6czBnA6B5L1UBIOGHRYeCVtY90195nGhd32Y0YEmO3QNfUUw/X0woQ98kjDZMWmCXcIqGFRPzJAV1ee2LU=;20:37cONUrhFnD65Ug5W4EVoVPLx+eiat60KwC7fovZy+pBC3kwStPQLP4moYVXi761J1KBU/ijUOF9SkAbSFqEr4YHxWMQPP+8YrqWbE7/IZ74mvIY356tVzmv9gf3iKRgDJAvOgcur7ZjHtv2JhxcapU66cTl+oOfSO3sg6t8lB0aaL6TJPH1JSPqndqKvhwso3nbK1TzEuGOSPm5m/Jyv4KvAmn9oaytx+SXGC0v49RgyHcFrNo6gjfKO0ZJMgTmit3oTQM2KZB1sz3QeAjRV1nnzAufCrZP0q0KGuV9n0X0+OQXOGPpE+UAuInV/0LFIrJl14GBbsZ65AD2f/EABIAAAa1PnZKri1r98vmZEndsMtmI8Ygk06T2gnj8HRk089gIpIjP6UNKKlcuQ9ybUX6Nijw4wKQEiTBT4HyIBwMbuss0khH6EkzPWvBN+5y7iz2yndYRALRcm/V9M/WGUx4VUgTVPWRYg5OkXzF5PG5k2jjEDTWZzgj+d/4t92T4 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(42068640409301); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);SRVR:BN6PR12MB1137;BCL:0;PCL:0;RULEID:;SRVR:BN6PR12MB1137; X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1137;4:0wxp20/3ELIEQQhs/JgfvTuEC+ry5OnnCB1/iL0uFvcb5A6ASeiNE1EP2i27BRTy5ii8gCzm3mQnL60E89uLQsL28R8+/HUqLoBYueION++pztWZMUSu1AA/ac1AdZdUw3gdfTZC5p4AQeMV2VkOqlWaP+qySnZaH4x2sDVscKz/i+ZsXqCIRXiHW8TRQChKcAewjwGKR3j7zPOIqtOnJcIBnY7IOdZwUd9p5r6mYuutQ1gCm4HHo/3Gf6hkBiDnmPicEoJIVIy4968zzunAX850/esHWWUUl5P8BgbeDgrTxvX8FRT3lX9WkxkWEiQ5sgdntL+Ns0ppqt0DzNrIG0Wr6cuCbiABdhXiM5kULYVq0NqWvwkzNygh2xQoDvs1nu5x1Mvb7QbmxnKhWLk0hZnroNsDnJPqychr1HtQc0DJFxsLE+Mdz4Wmljsa0isskj7eFychQjz0C9CxOvbvQQ== X-Forefront-PRVS: 0066D63CE6 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(189002)(24454002)(199003)(377454003)(76176999)(50986999)(189998001)(2950100001)(305945005)(54356999)(33646002)(230700001)(110136003)(77096005)(65826007)(86362001)(15975445007)(586003)(81166006)(101416001)(19580395003)(36756003)(8676002)(4326007)(4001350100001)(19580405001)(68736007)(83506001)(105586002)(81156014)(7416002)(106356001)(3846002)(6116002)(31686004)(42186005)(50466002)(93886004)(2906002)(64126003)(7846002)(66066001)(65956001)(7736002)(65806001)(97736004)(47776003)(92566002)(23676002)(5660300001)(31696002)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:BN6PR12MB1137;H:[10.236.18.82];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjZQUjEyTUIxMTM3OzIzOll6dDRxbmNJektGbUZmaWEvZVc2Z3NEeTg2?= =?utf-8?B?MlNIbWVvQkRad3JYOVBYbmNlTHhvendxU21MMmg3OWIxZzVWVnE0RE9qWXdj?= =?utf-8?B?bHphSERyYTlud3kwSi8vQVdzR3M3aUNSMU9FQTE5YzV2R2lLSXE1dVZFQ2p4?= =?utf-8?B?NU9mYk9WbHRCRlNxRS9YNUtyMHA1QmZIT0dLUytGUHRDaTZZUWJYQ3UrM2xR?= =?utf-8?B?Yi9jNExRbER3U2F5cmF0US90Y293RlFCVjhiRGxUb280MHc0MTgrY3dGTXlS?= =?utf-8?B?eEt4Z2pZVjEveDRnNjhhcFBDc0tEY1Z1UzcyRGlrLzI2cFdoUTRZT05TbkIw?= =?utf-8?B?Zjk1MGhncDFuSHovR1M3MVZxOEo4L2pzZzdidWRxVnhlMkxXOElTWXdsSlIy?= =?utf-8?B?Q3MyM1hvS0dGenFXTzlGallZOTlJNGpBbXlYd1crZHpuSHJsalMvc0l0VTB4?= =?utf-8?B?eVA0ZmhCY0I1WmZlQ2ZMcFRXOGxCQ0Z1Qms0QThFTU1iclNSRjFYMnVCRmpw?= =?utf-8?B?aTdXazdJZ3c2MFU4OHlqWU1tRzFZZ3I1REZMTWViN00rOXVYdFJRUytxV1l3?= =?utf-8?B?L2g0akZYVURSTGp1Tlp5VjgyREhQQkNkb1lnT0hSRVJ2eS9Sb0JCMVVCK0JP?= =?utf-8?B?SWY2Ujgxd2JTMnZTeGRLQUNCV21MdkJZMnUvY2xZUi8waVRlL1RTZmh5bGdD?= =?utf-8?B?WmZ2bjRONlFwTm0vYTFuZXQ0ZVpMWnE3TmRuOUkxajVTQ3pYSEdyK2ZFelBy?= =?utf-8?B?aWV4bWVETUt0VG1pWU82ZVZpVkowUXIzdVJDa2l5RHFwTEVYVnU2aEZiSTZV?= =?utf-8?B?SXhiVytJdmJPVzdPd2xjK1lTZVl4M3R0TlY4cEFBSmZCaUZsdlZaWkRpL1ND?= =?utf-8?B?ekgxT0RmeGR0OUNoeVhlbkJIWXUzZk9FRTRiVTQxd1paNlU2ZlFPOVdqa0gy?= =?utf-8?B?ckNPSi8xTDFqTkpvcGFFak0zOEtYNXVKK2FGbFhicjFZajQ0VkkvV2RGelFy?= =?utf-8?B?UTZCS0JncG1yejJuL1BNR2dYU005bFhuejduTWpzR3NvMDFQcmZoTTMzcnVF?= =?utf-8?B?QlQ5Ykd6cmhYbVY1TE9FQk1vSkgrc2xPZDhTNW1sZHFMSm82VElGd0VWVnhm?= =?utf-8?B?eU5aYTdKSUlhNEFUZWg4OGsxTXVkVC92Lzh3RVJWWEZBNzJ3SHMweDJ1b1Ux?= =?utf-8?B?VkxXYVRhb3RuMGI1cnU2SUVMa2dEempKU0lqY0t4ZTZIdTRkWlNMUW5EVW01?= =?utf-8?B?R3RkSTJRMmVNT0RhQjVtM2JEbERaZmx5RlNycGdIQmdtOXI1MlBjeGc2TDlM?= =?utf-8?B?aGh5QnhJUk9IemExQUNHVFJ0ZFB1VU9BQXJBK0x0TmNkR1F1NEJlajBUN0p4?= =?utf-8?B?cDVKTUhnWXpTRWllUlhrRzdVQTkvQnROcC9XdENGNEtFajg3Y2hFdks3TjVT?= =?utf-8?B?YlBTWHp6OUl5enVleUloV2xNMUJaRGI3WnhLZ2JnZkl4L0pKUFpVSHlZdlF5?= =?utf-8?B?MXFsTG1CNnZLR0ZGZG1OWHRqOTJYeWt0Y3FWd2ZoT3FsSTRURVFQcGtYS2k5?= =?utf-8?B?RzVGRVI2Z1kzZ0FSZmtrOC9QMlF5VXhqUzNDVEZHZUxCR1A3WlJvc2R2M3JK?= =?utf-8?B?QWRrNzdkaWhYSk1lbHRTdXRQQS9aTlNZRlNkdnJXZEF3cUMwNjRuVDZKaGZS?= =?utf-8?B?d1BDbis5aFEzUDNZakpBSmF0NGtyQkhaKzFqZHZhTSt2dkkwQ0FFOC9ZRnJy?= =?utf-8?B?enNTUnUvZjNkUmt1dU5WYWdZa0JRbmp4N0FiRlR1UWcyZnBnSUNLUjFOaXBZ?= =?utf-8?B?aFZKM1NkVWozaEsvSTgyTUZvclJ6UjB5MVBOMElXRGV6S0RWSVNwaERwUHFK?= =?utf-8?Q?GYSfaTOF3KQ=3D?= X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1137;6:8dYtwAel7a8XZuTi0HpofKNaZ1zafG2UlFk4DJd+DWs8D3WroPCArLQ+qOLln1a18wDWoXMjrlktA73UiAV1LEptA9JHnk5Hdysql5bbHK/r+Q3doXu8Q+L1iloBLrW+GH3Q0vGP2CBJBv/tcObs2dn7wxkZR9UGqFPccwGzsuh5CWkJTna7MA+S4IW53m2MamVpTwg+rRjdhEseHzq1bTm3d5O1aw1s7GWbDTIe9wNA01ihzoXhIB+6EAGbAEBBjLFKfvziKnpwia/brDUBx3sR44LnpWiXUzu+cy40c6fx7yev9i84r+lh3JFSlLgwFhait5K3uQ7N5VohCpKhbA==;5:6XFb83GI9Wd0N31c4zBHt2FPGA70CmNVi+osHbAt5LkxOPNTnJSv2mRa171YB7PZJ1DuuZOnqRP1fhoZ1MFLEZDmXYIKZyeFubWXWViptGL4UrZjQYBZU/QeoE5j4PpqeCEdB9QkCP5pJM0PTNl0aA==;24:1xzBKF4rbFlTJMtYQJHIH/kN+f76zxP0/hqPrF9R4E+rmKvxXRTUv2ZrwFIM/tX2KJvg1sVLG5j80V2Zt4kKptm7DYY7yM0uM9pNNIuCwBY=;7:DSzUtpfrcf1hmmCX/3+jj1H0Zt+senENbnAypfoa4UtpO23bxHcdXe28LE0+pEtho8mP7ceFFlWnGU6Q1OMDcHR76CywCsJ+tZr27UjGhex3V5ekoXq6eA0yGrdUy7Ajelg9hkn3FvgyorjyAcT7eEm83voQthH+uuKYoDtmSuIGmReubRpfLD+OU7YuFrru88nwJXDyYn/JEZ7phtvB84oBZpdnn46kJvHRa7lCcTGnDzEA5u9uaKMLlnRR2yeR SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1137;20:7mPJPTJVo8B+POH1UedGU1hlOem830e9YLhvi20tSTrgvsD9rNtBJwd59RARaGW3sQojQFEFXzW9ZTT3GwlKPzgfM62yxMedJHV4gefBYaFDOAbpUMLM6o/w0qDb+sFFwlLFZJo4+Fwftqrua6fbSS9QbFrCS86KQfQQ6LYPrkmzPaehhUHVROLIdMVIURQ1eCYLhOaZ2cfwkkrSswlxRkT76NsrOnsJinXKavGd2TWbcsW7QR2M6GFa40MSIQew X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2016 17:08:09.1584 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR12MB1137 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/14/2016 09:51 AM, Borislav Petkov wrote: > On Wed, Sep 14, 2016 at 09:29:41AM -0500, Tom Lendacky wrote: >> This is still required because just using the __va() would still cause >> the mapping created to have the encryption bit set. The ioremap call >> will result in the mapping not having the encryption bit set. > > I meant this: https://lkml.kernel.org/r/20160902181447.GA25328@nazgul.tnic > > Wouldn't simply clearing the SME mask work? > > #define __va(x) ((void *)(((unsigned long)(x)+PAGE_OFFSET) & ~sme_me_mask)) > > Or are you saying, one needs the whole noodling through ioremap_cache() > because the data is already encrypted and accessing it with sme_me_mask > cleared would simply give you the encrypted garbage? The problem is that this physical address does not contain the encryption bit, and even if it did, it wouldn't matter. The __va() define creates a virtual address that will be mapped as encrypted given the current approach (which is how I found this). It's only ioremap() that would create a mapping without the encryption attribute and since this is unencrypted data it needs to be access accordingly. Thanks, Tom > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Lendacky Subject: Re: [RFC PATCH v2 19/20] x86: Access the setup data through debugfs un-encrypted Date: Thu, 15 Sep 2016 12:08:04 -0500 Message-ID: References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223859.29880.60652.stgit@tlendack-t1.amdoffice.net> <20160912165944.rpqbwxz2biathnt3@pd.tnic> <4a357b9b-7d53-5bd6-81db-9d8cc63a6c72@amd.com> <20160914145101.GB9295@nazgul.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160914145101.GB9295-K5JNixvcfoxupOikMc4+xw@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Borislav Petkov Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Matt Fleming , x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Alexander Potapenko , "H. Peter Anvin" , linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jonathan Corbet , linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kasan-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Ingo Molnar , Andrey Ryabinin , Arnd Bergmann , Andy Lutomirski , Thomas Gleixner , Dmitry Vyukov , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Paolo Bonzini List-Id: linux-efi@vger.kernel.org On 09/14/2016 09:51 AM, Borislav Petkov wrote: > On Wed, Sep 14, 2016 at 09:29:41AM -0500, Tom Lendacky wrote: >> This is still required because just using the __va() would still cause >> the mapping created to have the encryption bit set. The ioremap call >> will result in the mapping not having the encryption bit set. > > I meant this: https://lkml.kernel.org/r/20160902181447.GA25328-K5JNixvcfoxupOikMc4+xw@public.gmane.org > > Wouldn't simply clearing the SME mask work? > > #define __va(x) ((void *)(((unsigned long)(x)+PAGE_OFFSET) & ~sme_me_mask)) > > Or are you saying, one needs the whole noodling through ioremap_cache() > because the data is already encrypted and accessing it with sme_me_mask > cleared would simply give you the encrypted garbage? The problem is that this physical address does not contain the encryption bit, and even if it did, it wouldn't matter. The __va() define creates a virtual address that will be mapped as encrypted given the current approach (which is how I found this). It's only ioremap() that would create a mapping without the encryption attribute and since this is unencrypted data it needs to be access accordingly. Thanks, Tom > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f70.google.com (mail-pa0-f70.google.com [209.85.220.70]) by kanga.kvack.org (Postfix) with ESMTP id 0FA1F6B0038 for ; Thu, 15 Sep 2016 13:08:16 -0400 (EDT) Received: by mail-pa0-f70.google.com with SMTP id mi5so99254638pab.2 for ; Thu, 15 Sep 2016 10:08:16 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0075.outbound.protection.outlook.com. [104.47.34.75]) by mx.google.com with ESMTPS id d186si40164146pfc.72.2016.09.15.10.08.13 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Sep 2016 10:08:13 -0700 (PDT) Subject: Re: [RFC PATCH v2 19/20] x86: Access the setup data through debugfs un-encrypted References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223859.29880.60652.stgit@tlendack-t1.amdoffice.net> <20160912165944.rpqbwxz2biathnt3@pd.tnic> <4a357b9b-7d53-5bd6-81db-9d8cc63a6c72@amd.com> <20160914145101.GB9295@nazgul.tnic> From: Tom Lendacky Message-ID: Date: Thu, 15 Sep 2016 12:08:04 -0500 MIME-Version: 1.0 In-Reply-To: <20160914145101.GB9295@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/14/2016 09:51 AM, Borislav Petkov wrote: > On Wed, Sep 14, 2016 at 09:29:41AM -0500, Tom Lendacky wrote: >> This is still required because just using the __va() would still cause >> the mapping created to have the encryption bit set. The ioremap call >> will result in the mapping not having the encryption bit set. > > I meant this: https://lkml.kernel.org/r/20160902181447.GA25328@nazgul.tnic > > Wouldn't simply clearing the SME mask work? > > #define __va(x) ((void *)(((unsigned long)(x)+PAGE_OFFSET) & ~sme_me_mask)) > > Or are you saying, one needs the whole noodling through ioremap_cache() > because the data is already encrypted and accessing it with sme_me_mask > cleared would simply give you the encrypted garbage? The problem is that this physical address does not contain the encryption bit, and even if it did, it wouldn't matter. The __va() define creates a virtual address that will be mapped as encrypted given the current approach (which is how I found this). It's only ioremap() that would create a mapping without the encryption attribute and since this is unencrypted data it needs to be access accordingly. 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