From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Lendacky Subject: Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear Date: Thu, 12 May 2016 13:20:45 -0500 Message-ID: <5734C97D.8060803@amd.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160510135758.GA16783@pd.tnic> Sender: owner-linux-mm@kvack.org To: Borislav Petkov , Matt Fleming 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 , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Ingo Molnar , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov List-Id: linux-arch.vger.kernel.org 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. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bn1bon0064.outbound.protection.outlook.com ([157.56.111.64]:13888 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751693AbcELSf2 (ORCPT ); Thu, 12 May 2016 14:35:28 -0400 Subject: Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear 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> From: Tom Lendacky Message-ID: <5734C97D.8060803@amd.com> Date: Thu, 12 May 2016 13:20:45 -0500 MIME-Version: 1.0 In-Reply-To: <20160510135758.GA16783@pd.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Borislav Petkov , Matt Fleming 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 , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Ingo Molnar , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov Message-ID: <20160512182045.B8DBFVE-Zq4O4LR2sZC4xhGiSHjqXwBKnJCWWITH1Mc@z> 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. Thanks, Tom