From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756152AbcEXOyr (ORCPT ); Tue, 24 May 2016 10:54:47 -0400 Received: from mail-bn1bon0056.outbound.protection.outlook.com ([157.56.111.56]:9536 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754796AbcEXOyn (ORCPT ); Tue, 24 May 2016 10:54:43 -0400 Authentication-Results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=amd.com; Subject: Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear To: Borislav Petkov , Matt Fleming , Leif Lindholm , Mark Salter , Daniel Kiper References: <20160426225553.13567.19459.stgit@tlendack-t1.amdoffice.net> <20160426225740.13567.85438.stgit@tlendack-t1.amdoffice.net> <20160510134358.GR2839@codeblueprint.co.uk> <20160510135758.GA16783@pd.tnic> <5734C97D.8060803@amd.com> CC: , , , , , , , , , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Ingo Molnar , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov From: Tom Lendacky Message-ID: <57446B27.20406@amd.com> Date: Tue, 24 May 2016 09:54:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5734C97D.8060803@amd.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: BY2PR04CA0080.namprd04.prod.outlook.com (10.255.247.48) To BY2PR1201MB1109.namprd12.prod.outlook.com (10.164.168.17) X-MS-Office365-Filtering-Correlation-Id: fc1fa034-921b-44fe-ced7-08d383e3544f X-Microsoft-Exchange-Diagnostics: 1;BY2PR1201MB1109;2:lEM90Y7Ww03ORn1DcGTtQxBl4m54alLItCr/ekBpHfoza1GFfRjLO2C/xMMPILbl3EJuygq52Pzb2dbeBqcJ0WHIxqIs/qc+v1qwAihGbVdD7xFCrtesxdwnYqpMBncjdMAGDHDKzhFoEZaOB08N2zrkck+ad3gl0+oLfPQg6QkNhk+iJyBodtaX0cI7sjck;3:K29oCVzv7liEmifkYqsWdHG19bJWt7XKhxRLf3g6Wm8Ian5D22VBRdi9pQuCPbfE45Z+cDbDuC8TAIDcoxkrGtWCbI3EPbevJ0Mzb37ZGTEwBvxj3kXUt++ZwoKsd1/b;25:KuyL9j/rwlokp7pi05rvFrHkKfbu7vTFDGtIjaaQPYWmfk8Tbhy58fM8j9NpTsQh0A3mTh4zAI279Agv94rZ/OEyPeVg8T3X7kne/XDNPO0xykNAes4iKwDVKe1TVm6GtDfPmOJXR58kFb9BSGNrrWaKSBnskDGR1PyYCK0bQW9StpOn0DvZk6iSCgujA2EA0hRW/pZMvfGRsbu4kHbkQk01XSP6FSp5II4tGX5+EPLwlYuWJVmYXhvFCcm6uwYXsjR/WuHlh0ZBUAk0cKLDY1Gn2v3w1AsuQTIdHZXweNk9AJeDMfcGJ1ZzQc6t8gTfqQbhx6Uijk5c3vLl9nNXXFgkHrz2IR9inLQ6E5FoQsYZruYSNIu9EImkLvmo3leysAn0seaY7Wtpw1GtC8afzk07rOYrlBjyDslH22Hbe7Q= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR1201MB1109; X-Microsoft-Exchange-Diagnostics: 1;BY2PR1201MB1109;20:ql9E1BZ8xERiKzcprYLtPcVMw1cLV2SGNy0BD9Q9Jb+JF5DPqH36wuHLM4e0DPSgCClHf00mIyUixeoBKQ02q9t+ThYjCAnGBqJvWa+hU2B/PhWP0AzA14X6TP+S8wGVojKA2p7m2bRJyG4jqRhOhDmhkp6agoFDonSkqDlBfGuRPwO/9V2dIwPxN4FKKddGtjShsIYth+O9BLniBNC2nLDMcLkG2nC4iWsuXbWXrP02zj8TmxGcT7zbm43YbUFjw7P5Yajyoqlg65ftlE921KN7QKyTCqnZlZHiTKXDCHVkE8Sr15IId0ZXcenP3Jbr0417EUwXMOQU5gBLaUOv+EX8cpsJX0ZihoSdvHS4dQbGRL6wNXXi9BIQvR4qj6J9+01n28JTVJReCG0TOMcJmCXPOiBVxslMzETcyoXfb3xsHkkiygxktO9cbaFJth/Z2furriGgdq3Mpc1mgWPwYmG/ThNBb/ega07tzP8tU3v4AKXEOZrDXrLD5QcRsrjG;4:Ovz+WE0Qpp+0XQARMspWPEr66pwjhXcMb47lMnJJ0TDlHuMPM9BdeoAwY/6lV57vfLYoYk2ro+VQOpbPqtOM9XJRg1vC96CbsZApGntq8kv+B7H+jCvlBfT1/XpwZxwaMpea5SjDrYJk0ZkYnm5jwogvgCXw0xDO582E7Un6EtTAMy3sFpeg24FqbQGGUOmP2ih9EoyziipLNZ/3Ln2y+tf6U17UR3iZLSxhvbYG2c5EibpLQZrLOOoI4CiVjYj8sOVIch2dRS0/8JNfq89f9uMMgrYKS7BeuyVJmooqE4IreS3ckTrYwfHTlx2MW0C5J1HYkFdJrDuHm3sPqAxu7q1u1rMHTxay9ufGDnXPESk4VVRxcJqXFr3si0LYaFtEHKAZfntH5ANA17Qr1H3+yw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);SRVR:BY2PR1201MB1109;BCL:0;PCL:0;RULEID:;SRVR:BY2PR1201MB1109; X-Forefront-PRVS: 09525C61DB X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(979002)(6049001)(6009001)(24454002)(377454003)(81166006)(8676002)(4326007)(2906002)(77096005)(586003)(65816999)(2950100001)(6116002)(3846002)(50986999)(86362001)(54356999)(76176999)(33656002)(42186005)(93886004)(92566002)(230700001)(83506001)(23676002)(5008740100001)(97736004)(47776003)(66066001)(65956001)(64126003)(65806001)(4001350100001)(189998001)(50466002)(5001770100001)(5004730100002)(36756003)(217873001)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1101;SCL:1;SRVR:BY2PR1201MB1109;H:[10.236.18.82];FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjEyMDFNQjExMDk7MjM6NXNGSDAwaHI5eWxjOGV1R1lLelRaMk5o?= =?utf-8?B?UGo5TzFZTXJQM2t5WGZObmZLZHpTcTB6Sm1UdjBKT2RwWUE0bVplbmxCRnd2?= =?utf-8?B?Q29XeFdpaFZCRGVWcWNrbk9TOTN4Z041ZVdmYXEvUTU2STBhcndDcHJ6WEtK?= =?utf-8?B?T2FjTjhIVlkxYXR3KzYxTTlrV2N3MEtmbjIyRzVXT3YvS3RsVVc5T01vbnls?= =?utf-8?B?SnJKRURlVFZCeXNKaHd3M3BqQVVPZndaUUp5OGwwUkd5TytPc08xY2xqdmV4?= =?utf-8?B?MEFsWE1FRmgwbTE2MWhSUEtwMm5CWjdBRnVnR3Q5enhhdSs4WVA4Q21jTFdC?= =?utf-8?B?RE1pVi81MlY3UHR6SkdQOTdvOGs4OGhlK2dON1MvZzRKUkpvOTlwcW5PZnpi?= =?utf-8?B?bi9FOVY2ZTNaRGJSTkg3Wlp2dmpZTDlvNElySWRKdHgvdU9FcG1UM002Wmts?= =?utf-8?B?MHUvaStGQXQ5SDN6SzhXZjN5WDh1WklPaXlOdkpGU0JoZjV6TFM0ODNId1gv?= =?utf-8?B?cXhySGFET3AyYkdkb1U0OTVIdGY1aW1FMGw2Q3pFL1VtY3JWZVd2ZWlRa0Fr?= =?utf-8?B?OExHWXFwSmQzUDVyZkV5cjc0L1ZuUGR0MU5mcTZONmRMTmtETE1jcUtqb0Vt?= =?utf-8?B?WGt6UStSanpKQmtSWVI5YVBkR2VKay9GUnJzTnpqcTdNcXpXRmtZeWFlRUdZ?= =?utf-8?B?THJxbTVNUTFOdnlURm42dVQ1VGx6NkttSGc3amZLY3dod2p6TUtOK29zSDlV?= =?utf-8?B?N2FobW81MTJaYk1XSm1icGkraVRJdmhxQStIa2hVNXk0dFBwZHE4RTFrYXhj?= =?utf-8?B?QjRLWUlQSW9TS3ZXWXRxQkR4WXYwLzlvV1ExMVpraHlVNFd4U1RHVFRNQkE3?= =?utf-8?B?VVo0TW5KT0pOL3NqV2o2QzRvby8wRy92aGdhdkFKR2hoKzFsQWJWWWNnU3pk?= =?utf-8?B?ei8wdVkzd1ludkRiakdDRWRjNGNiaUlta0RqWFZZMEtRQTdqR3V2ZGdnamFK?= =?utf-8?B?ZjYzcnhIbXB6N1h3WDVDaXpRaFdrL3lKYlZTWkhPRGZldk15VlY5VmhjTDRI?= =?utf-8?B?UEhPc3dZcUE3K0NPdXh4TU1HVkhJR2lUd2NhWGY2Kzg0alo4VkdSVFljcTZP?= =?utf-8?B?YVFNSEpIaFFUT2JNK1YvWVc0eElUOW5KOU1MekpraVJrQnR4VHp2QWp1K2I1?= =?utf-8?B?UnBWWktlREVjeERTT0ZYcUNJV0E4NGhFQm9BTVd2L0Y2TXFoajZiSjR4MXFa?= =?utf-8?B?OXlDS3kyclBpY2JMMHIzU0kvZWxlemt4YkEyYWg0N1ZSUXBSZ0lLWVZOYzM4?= =?utf-8?B?VHhzM0d4VFk3SFFKV3R1aDhKZDZTVHJDMEw2WG1aV2Foc2p6ZGgwem1LcXho?= =?utf-8?B?cWhHcjY3YUhPTlp6c3hMSzJrVXEvRURNbnowK1hIaDZSWE9pcE5KTitOZENw?= =?utf-8?B?NFg3cHE1a2tXM2ttSmEvdk1EN1lFSytiWVdIdVEvYVZCWHduQWVnUnplY1Jv?= =?utf-8?B?R3JmVUV0K2h3WTgycVNXbkdiZWZ4bEQzV0VGUmlKZWk2WFN3ak5mNU01Ulk2?= =?utf-8?B?MlptTGdhVDlrbTBDZExGUnFUVWtxZ2pMZz09?= X-Microsoft-Exchange-Diagnostics: 1;BY2PR1201MB1109;5:aV5QXxWQStQoEOEn5nosGKewKbm8DKjLT1zSsc5SqJjuW+Zx64bBPih36Si6gwv+jGSWywvE0mCNa7Duugd4A4pvBgTnbhGV2arsXlfNPW9XyN+5Nrg9A4Grda8XZHhhHMqXSdr3mo4JMu0K7lSenA==;24:IbdxKChG4M1w6ITOo15qAVVXSeUGV3jTROXOzHfj+5mzEdXAgn/krU4ig+dJrbQi9ab68ItBGexCEJoPAJMHJGEc+KGAYHdbscKd9x4FNlI=;7:8uyWjM2sjLBPgfvBHtIVHEse0ASepZm6A/MxKgAyXk2KVFSnsG7yCy3gubKp4hCor2oLmxqy7g8I4EBS8iGstgQXJxRcFMgo9ZaLcKER/U4kvQ6Me5XOrKViYlodnEcTreBGZ6iYfU8DQIME4ykvDJrLIZ0GXbI8THq9WavWa28FmgkIdFFl6amaagrjkqlN;20:EVi5GYRwNHqtL9A6vsJDHjbUFgOYVJYCAPLH4IwUvShecKZICwB4wiWETBd+gTsaDGu30GmCdW6g9HOP4UwA2RmB3HJm6eRoh/O2tn0plut7BHoSp2k71/14+Mn0AtuBWxFpvGiFiRysz4HYceINhUxAzl59u8oHZpiosOltViMTrTh8krPp81Kl8dvSwOhWThc3rd3+QyGn+3wqSPEPziYd5nkM2CRLB8JnYYrgnMgx9SqF1Im03mxmxCb97GVs SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 May 2016 14:54:37.0171 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR1201MB1109 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/12/2016 01:20 PM, Tom Lendacky wrote: > On 05/10/2016 08:57 AM, Borislav Petkov wrote: >> On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote: >>> Is it not possible to maintain some kind of kernel virtual address >>> mapping so memremap*() and friends can figure out when to twiddle the >>> mapping attributes and map with/without encryption? >> >> I guess we can move the sme_* specific stuff one indirection layer >> below, i.e., in the *memremap() routines so that callers don't have to >> care... That should keep the churn down... >> > > We could do that, but we'll have to generate that list of addresses so > that it can be checked against the range being mapped. Since this is > part of early memmap support searching that list every time might not be > too bad. I'll have to look into that and see what that looks like. I looked into this and this would be a large change also to parse tables and build lists. It occurred to me that this could all be taken care of if the early_memremap calls were changed to early_ioremap calls. Looking in the git log I see that they were originally early_ioremap calls but were changed to early_memremap calls with this commit: commit abc93f8eb6e4 ("efi: Use early_mem*() instead of early_io*()") Looking at the early_memremap code and the early_ioremap code they both call __early_ioremap so I don't see how this change makes any difference (especially since FIXMAP_PAGE_NORMAL and FIXMAP_PAGE_IO are identical in this case). Is it safe to change these back to early_ioremap calls (at least on x86)? Thanks, Tom > > Thanks, > Tom >