From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763885AbcINO3z (ORCPT ); Wed, 14 Sep 2016 10:29:55 -0400 Received: from mail-by2nam03on0071.outbound.protection.outlook.com ([104.47.42.71]:40596 "EHLO NAM03-BY2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757910AbcINO3u (ORCPT ); Wed, 14 Sep 2016 10:29:50 -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> 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: <4a357b9b-7d53-5bd6-81db-9d8cc63a6c72@amd.com> Date: Wed, 14 Sep 2016 09:29:41 -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: <20160912165944.rpqbwxz2biathnt3@pd.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: BN6PR17CA0009.namprd17.prod.outlook.com (10.173.147.19) To DM5PR12MB1147.namprd12.prod.outlook.com (10.168.236.142) X-MS-Office365-Filtering-Correlation-Id: 2e8ab0a6-c373-4f13-d247-08d3dcab9496 X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1147;2:9SYDFe7B58qQmuQfeLA1vvmcMFD3NhSejGLWLETKNV6w/ugI4tGRW2qqYd5fraN6xSdNqI+dsU3qHzSqkrcuC7jwZhEInTxodCSZaxtBYTFsOPQbEORRtSFjmrL9s6ZDa3DLqSWaJn6ZRThM4OJL4cGGB3MPS/j8xIolMgBTd0vrYoswxABTd7AluosOkNr9;3:8bxzDN8Lmfm4+49ElstIi1x4P/7hztQfbndEh75rHRqVBFz+6kSejBAZODveIVKjlDwAKPa85vEWFnDF4zrajZSzX6VP6qHVZ7Kr9dsa1bUMCSEQd/VTkIGNr7Pi/aS7;25:Ctzqq8f3a5JxrUWNQWn5RmxXIrtbQWHYKnDIJDtky6GchPmOc/mtbSEkqF4JP6Ylw/SSSJC2lfxmcypt+Sesz45dq3hoe+5e+d47n/gtYujBdG+EqATiWafL1nCRJieObpQrNFMXgxZaWXPDOXlH2F46QKmPhfeh8R6JTDDoLbhjak9ysQP+jP0eBFELnW78GWlOfr6lCA2xrwtLkP3dsH2VIlLdPbFW8wE7W89Aa/QNKx8O4yBh1O7oJMv9Pwq+8WbFhtbdvC3bRMnB/1Sd5kll68lCid6NqGI5mtdcGN71LVFiHf9mdVkB5a5bTgmyO2sM7vylH65cNK6LuADBG/sszZUhruSXPyNTNt5gzU0gWRjgRby4B3xjV5nhdAD6x712fIuVLlLj+tk7WLeIKK4qAS7jlmI+bGLLAd8Eguc= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR12MB1147; X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1147;31:oU1b7CI6tcUxy8mjnTgTdsVkvYn02doRM8lynV4uApf9QKbm4f56vjZh5tWF2Gu6uVYU7gMCQBGGF0LogDnr/9IfTNh068OdY6eaN9HCo+JZwaTqq+r+4tdaEytZoRy0Yn3gSv3/QGAo7q9cYsy0cpox9rIo4JWPUzGVJafYbJnxs+Xj8XW1Lu/8cfR34/Ly4idN9CiGXJwaxTgc9mY3O3TBtzvZggr+i5gmDI8QoWs=;20:VC5xcNX6zPKUHV/vn4eUvcM+8j6B4x6jhqAgUAcWbLe478tEi8PG6spvZ86XR97qbf12DQfysOA61taMVVOKtw4FUhNMvRjqRTWsnHnjqnOoQIWEfnc2M3uDg69gUMHG5F4nOD6TwyJUdIAOg4K8+ChtOCNyUoflTEuLBmvJYYzNey5lytbiIrpOsiYxofdIRtSHJNNFr/6MjuI087uc/cCsoudVRyJ3K7jPg6jvECC7pkB/k5xHbBIHy6ZGJI5zzfir3fRe70PysDczW9mRssXmwqN8u1s5y54Qc7+OTgY2VxmmawYyHEMR1UQPNeWbYUmWub6dctYBzvHteoFCRD0TabaAuV00x5rA2zpKRo9IUiC08yGSCoPQk0N2zWS2SyLwJqmOt8BHeWwni3eHztMnO+QQ2S3ntZHYDwhu/2iFXyie0yyRy62tu/CIzN5/ikstJCJbWsu1pMW/VgibBDVm1xDwB3jgJWEoejNOc0aKDLGFmL43ExeXHcovh/5f 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)(3002001)(10201501046)(6055026);SRVR:DM5PR12MB1147;BCL:0;PCL:0;RULEID:;SRVR:DM5PR12MB1147; X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1147;4:YgCtIjXl3lRmRyauSIJHaPSGX2qngzdIH3xfPq64i6QAnZ2V+qIa2FTxkBL/AQrmUSlm/N8EnTWBneDeTbGDi6lDF+WLNTEmQMK6eiGB+nQKso75JygNtiFcjV513FrJUCOBj/JSSGKzhJotSyIHgQrAUqFAYOvCxKa+buK2xsk6B6dY1qZUQ5PXYHl/s0fZLeIuRIxZ4fAAEW+lyM4oGg/Sb3z5JcWltDH1aX6tt40zx+cyDP4feIxRB3Ft1Kkwwus2JhcWo0AX1rY13JYZtNBKngAMYga0DHPBUgXjDQJkGEgN9Ixg69bPz58lu7KjYVWVYYipKLg+PQBmO2wh2bnl3RdRTTPUL21U/3qLmf7hFeo5AfWUu8gH8T+g/RBERDTPVSSne/drKF0qevLcVizqVWsQTX+iTmynJxaOQFz9hbh4RiTM5u5uDZdzqJgb X-Forefront-PRVS: 006546F32A X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(24454002)(199003)(189002)(377454003)(5660300001)(92566002)(4326007)(83506001)(47776003)(31696002)(64126003)(106356001)(2906002)(7736002)(66066001)(7846002)(65806001)(19580405001)(42186005)(31686004)(105586002)(86362001)(23676002)(50466002)(33646002)(19580395003)(65956001)(4001350100001)(68736007)(50986999)(65826007)(101416001)(305945005)(36756003)(76176999)(2950100001)(8676002)(97736004)(81156014)(7416002)(3846002)(189998001)(230700001)(586003)(77096005)(110136003)(6116002)(81166006)(54356999)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:DM5PR12MB1147;H:[10.236.18.82];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjEyTUIxMTQ3OzIzOlVibXE4aGlpWG9HTnQrbEE2eG5SMG9mcDRx?= =?utf-8?B?YkJFcSt2VDJ0NFJSZzJ4Z3grR0xUb0hROWliNDhvK0JKZGsrdzRnclZqTjRr?= =?utf-8?B?NVdEbnVyaGNuWmJtbGs2dTB4OUpCbVhmVnJob1hzMnM3ZVI3Rk1WckE0YXda?= =?utf-8?B?V0lkZUVmaXBwZjRVZjNrRC84UU1iNFZpM2xwOEk3TWFKKzc0YTQ0ZjM0S3pU?= =?utf-8?B?TjY3WU1La1B6MHh0T0Z3eVFqaEU1VTVrWStPZFFXWFlFdjZzYUE1cGdKSVFJ?= =?utf-8?B?SFZUUXRaVldrU3I4RU8xNkNlUUFiQW1pUUpWNUdpSmtGYm1uNytjbSs2UWpK?= =?utf-8?B?bFprTUhKclhVek95cC9pLzdXZVdYaUZLM0lEZmJNbXg4MU1lWHFhV3dpWnNw?= =?utf-8?B?SXVEYkxNRzlweUo5SzM3Z3NMM3BQWm5lWElTZlR6Wk55WVEyOVVNam91WlQ4?= =?utf-8?B?RzFBR2xiSmJaRUV1TVlNV2tXSHR6SmZpRWFHT1NoWEM4bjNSWEQ0TXpJcWpR?= =?utf-8?B?THJqamtYcXJzMzYyVFVPVW03Q1k5RFpJbjEwZlVxSUk0R1h2UTBnMTg4MS9a?= =?utf-8?B?R2h1RVVIODZSSjNqRmdLZFpDVkZWanpxTERhaFBBaGUwOXZhc0hLQVNPL2Rh?= =?utf-8?B?WEwxUW1RWXFJNDhRNndDZDZYMnd5Z0NJY2FxYzdRWUoydEE0R0xkRjJidHpq?= =?utf-8?B?M1R6b0tjQUlGRVlYTW1qWVAzOERia1dEc1p4elNrd2Y0enhZZklKd2ZkZnQ1?= =?utf-8?B?NUFOTit6SEJLd0EzeHpjQ2F1WXY5L3Ixc05jRXZYL2VyMEhiWEdtVFJYSWJk?= =?utf-8?B?Rlh4OWFJSU1yS3lyMnRhK2tzaUoyZ0hveWR5QlN5MzhYWGN0cWJuczlMdkZI?= =?utf-8?B?TCsvVlZkVDV1NFB2cWRQQmpmTjZRMW03UnBTaklEZTQ0RXhDVGVMV2RheTZM?= =?utf-8?B?NE1GOXJwVlYyaWx0M2E2a09Tc3pBQ3gxU3hnS05lUUhIU3duVjJhQUxrYk55?= =?utf-8?B?VFhObmxmT1pCNU80TG5zZy9OOXY5WklVRkZPZ1ZZMHFJS29vNmlIZFFXTFQr?= =?utf-8?B?M0wrdzd4NFRIVld0NFQwWFlRbkx4NjZHVkY2WUZ4NVAzdjhnMHV4bUd2eWdH?= =?utf-8?B?SGJxZ2RpVlJVY25QbUs0T0YrZ3h3SFhBOEVGS28xc3B4dU4vVWRRZlNrd0FM?= =?utf-8?B?VUhhdkd0ZE5XVU9zV3BjMGNhRkUwd0FXN0p2aVFTdkdBWEdCZDRCbU45Q1Fy?= =?utf-8?B?MFhTZHU1YXZ1UGRTOTFiTkNlZWVRTU9KaDZkNmhoeWk5WnE1Y3J4RFoyVkh3?= =?utf-8?B?Q1J2SjdPcUd1ZCtHSmJLa3JiK29ZTDkxeThWU0pKdjgxalUrMnJoOENtM1hB?= =?utf-8?B?MlhJODM5VXpKUDQ3NFdlK1F1bUgrVHJWVkVrSHhLQU5weVpoSU5SUTNya1V4?= =?utf-8?B?dW96L3pVR0h3RzJhMGJ6TGtNWTREWmZrTm9GQThYeEtpQXJ6bWI1M2x2TXhy?= =?utf-8?B?aFdaSkhEY3VGS0wwSlJpaWw4dkdLUTJwVHlLelVURlJ3QW5rNUxWeVNTdVF4?= =?utf-8?B?R052K3FWRFVRTmhtdldEUVdrS2UvREdJZ3FQR2hyWjFDU1l6Y285bFBsMUd1?= =?utf-8?B?dCsrQ2gyVkF0cVA1djBlNDdXY25xLzRlVjRnbzYvV1YwWHpCZ1Q4Z0YyV2VI?= =?utf-8?B?dTVmYmRPTWlocDY5Rnl6NEU2VUJYQ3ZQcUJhRzVDRUxxQzFOU1JWdHUzelcw?= =?utf-8?B?WVNJUXVyV1NZUkIvc3pmeHUwQmFnUjZXb2ZtWHEvL2VDdzhKSkFtNHRDeHVx?= =?utf-8?Q?ukmg3GXYrUAuS?= X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1147;6:OuAv3WhAe2GYq/DWROgkgvlwJx7KPVfCW2l6IO0pvhDoK/u8kP0uhany5yhng4xHS3zW/nPz01C99TUfLv5QK2k8MuQWQ7qgFGk+yShbt6Q9NjY1+TTeny9GbLptpLDh4+w60abwmnbQuDmQFdW7ZGuZpSboAnYnZD4eNqWYLoKxz1iqCGfjJx+2zXZFTtz571GtyzAT4niMFFNM83ldtOmBUTdu1iI6PfxrR2n9HOqw2AFHEr5ZkkGhQ82JH+LlA2M7YIDsgcYx6/g/7rwvoAHGmjIPE5r1KFUq08e3eiBfacR/3I0B/1IX9YOU0x20zpcEiT5UBHQGAlLQtoblug==;5:AAavgArVTptlSH7fP7IzYZaNC+uICzF8b2rRr/tB/1WKoYYO0iaFKkddCif3dfPPOmRjzqbEbeXEvnnZwI2M/0hvzrEtv3phZ0qv9nX107JTbsXuI/T3Mw7UkJdhVdzIvOm/y737LSfO9Z+9usEdpQ==;24:GZyEF4jTYzIcsHhs6SXUjva9CPStPq/7Pul0egxKJAd8XMDwKaFPcME/1Ij8ofbkC8xyinZZG+cKDP2a9LSXIIwgtrYS4UUoKTBRGyvKBEs=;7:L1n+KXNPlVtwVfELAYoCZKb5t1eReFgLAHv5Y4XJ0olLxG4Wx+BwrQPky3bHMFXvZVcBnpVn0be4lrdgk+aEwqDMjjvLzyclDxL3IaGIfmXIr6jZaw2ETPpFYbuDG9ATFG4jEHhdOG0Yj2k4acxdfriQHYjkxZBtjbfnxOgd7oXvlutnZL6G/ODpaxNiRy45Quwc959yxRqW70HXO7v0tVfA73gG+NsMh/Y2hkdJMy+l0OYxDWz6oMDQAGiM+HtM SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1147;20:La9FV0F9UorP+9fA9DgZIdCxKpDWop7SYROaiE7vSomwdCrj3kt6fycpyrY1l7RgwJKO9YfkvpX+ZBMEIdcsJdWfJv2c6OYGu5iJ7olg04u5aSWQIoKrHGiqotMCUNv5IjA/ExaFDaSy9Ooqck+/V30qvDV8WS8gOu06oskSxUGBm8v19N1pDES6fChUxiG0E2hx28NI6A5Bgjx97Z1hQEeLKwpY1QcihGtxIG+bZQA3YOxMt4/fdQg+bQJ1hw3X X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2016 14:29:45.8444 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1147 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/12/2016 11:59 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:59PM -0500, Tom Lendacky wrote: >> Since the setup data is in memory in the clear, it must be accessed as >> un-encrypted. Always use ioremap (similar to sysfs setup data support) >> to map the data. >> >> Signed-off-by: Tom Lendacky >> --- >> arch/x86/kernel/kdebugfs.c | 30 +++++++++++------------------- >> 1 file changed, 11 insertions(+), 19 deletions(-) >> >> diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c >> index bdb83e4..a58a82e 100644 >> --- a/arch/x86/kernel/kdebugfs.c >> +++ b/arch/x86/kernel/kdebugfs.c >> @@ -48,17 +48,13 @@ static ssize_t setup_data_read(struct file *file, char __user *user_buf, >> >> pa = node->paddr + sizeof(struct setup_data) + pos; >> pg = pfn_to_page((pa + count - 1) >> PAGE_SHIFT); >> - if (PageHighMem(pg)) { > > Why is it ok to get rid of the PageHighMem() check? Since the change is to perform the ioremap call no matter what the check for PageHighMem() wasn't needed anymore. > > Btw, we did talk earlier in the thread about making __va() clear the SME > mask and then you won't really need to change stuff here. Or? 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. 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: Wed, 14 Sep 2016 09:29:41 -0500 Message-ID: <4a357b9b-7d53-5bd6-81db-9d8cc63a6c72@amd.com> References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223859.29880.60652.stgit@tlendack-t1.amdoffice.net> <20160912165944.rpqbwxz2biathnt3@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160912165944.rpqbwxz2biathnt3-fF5Pk5pvG8Y@public.gmane.org> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Borislav Petkov Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kasan-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.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/12/2016 11:59 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:59PM -0500, Tom Lendacky wrote: >> Since the setup data is in memory in the clear, it must be accessed as >> un-encrypted. Always use ioremap (similar to sysfs setup data support) >> to map the data. >> >> Signed-off-by: Tom Lendacky >> --- >> arch/x86/kernel/kdebugfs.c | 30 +++++++++++------------------- >> 1 file changed, 11 insertions(+), 19 deletions(-) >> >> diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c >> index bdb83e4..a58a82e 100644 >> --- a/arch/x86/kernel/kdebugfs.c >> +++ b/arch/x86/kernel/kdebugfs.c >> @@ -48,17 +48,13 @@ static ssize_t setup_data_read(struct file *file, char __user *user_buf, >> >> pa = node->paddr + sizeof(struct setup_data) + pos; >> pg = pfn_to_page((pa + count - 1) >> PAGE_SHIFT); >> - if (PageHighMem(pg)) { > > Why is it ok to get rid of the PageHighMem() check? Since the change is to perform the ioremap call no matter what the check for PageHighMem() wasn't needed anymore. > > Btw, we did talk earlier in the thread about making __va() clear the SME > mask and then you won't really need to change stuff here. Or? 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. Thanks, Tom > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f70.google.com (mail-oi0-f70.google.com [209.85.218.70]) by kanga.kvack.org (Postfix) with ESMTP id BDBAF6B0038 for ; Wed, 14 Sep 2016 10:30:09 -0400 (EDT) Received: by mail-oi0-f70.google.com with SMTP id r126so50951345oib.0 for ; Wed, 14 Sep 2016 07:30:09 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0084.outbound.protection.outlook.com. [104.47.38.84]) by mx.google.com with ESMTPS id 81si1617217ote.43.2016.09.14.07.29.49 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 14 Sep 2016 07:29:49 -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> From: Tom Lendacky Message-ID: <4a357b9b-7d53-5bd6-81db-9d8cc63a6c72@amd.com> Date: Wed, 14 Sep 2016 09:29:41 -0500 MIME-Version: 1.0 In-Reply-To: <20160912165944.rpqbwxz2biathnt3@pd.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/12/2016 11:59 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:59PM -0500, Tom Lendacky wrote: >> Since the setup data is in memory in the clear, it must be accessed as >> un-encrypted. Always use ioremap (similar to sysfs setup data support) >> to map the data. >> >> Signed-off-by: Tom Lendacky >> --- >> arch/x86/kernel/kdebugfs.c | 30 +++++++++++------------------- >> 1 file changed, 11 insertions(+), 19 deletions(-) >> >> diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c >> index bdb83e4..a58a82e 100644 >> --- a/arch/x86/kernel/kdebugfs.c >> +++ b/arch/x86/kernel/kdebugfs.c >> @@ -48,17 +48,13 @@ static ssize_t setup_data_read(struct file *file, char __user *user_buf, >> >> pa = node->paddr + sizeof(struct setup_data) + pos; >> pg = pfn_to_page((pa + count - 1) >> PAGE_SHIFT); >> - if (PageHighMem(pg)) { > > Why is it ok to get rid of the PageHighMem() check? Since the change is to perform the ioremap call no matter what the check for PageHighMem() wasn't needed anymore. > > Btw, we did talk earlier in the thread about making __va() clear the SME > mask and then you won't really need to change stuff here. Or? 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. 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