From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754335AbcIBSQI (ORCPT ); Fri, 2 Sep 2016 14:16:08 -0400 Received: from mail.skyhub.de ([78.46.96.112]:33678 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753772AbcIBSQG (ORCPT ); Fri, 2 Sep 2016 14:16:06 -0400 Date: Fri, 2 Sep 2016 20:14:47 +0200 From: Borislav Petkov To: Tom Lendacky 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, Radim =?utf-8?B?S3LEjW3DocWZ?= , 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 Subject: Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption Message-ID: <20160902181447.GA25328@nazgul.tnic> References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223646.29880.28794.stgit@tlendack-t1.amdoffice.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160822223646.29880.28794.stgit@tlendack-t1.amdoffice.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Hmmm. Btw, this patch is huuuge. It would be nice if you could split it, if possible... Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption Date: Fri, 2 Sep 2016 20:14:47 +0200 Message-ID: <20160902181447.GA25328@nazgul.tnic> References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223646.29880.28794.stgit@tlendack-t1.amdoffice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <20160822223646.29880.28794.stgit@tlendack-t1.amdoffice.net> Sender: linux-doc-owner@vger.kernel.org To: Tom Lendacky 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, Radim =?utf-8?B?S3LEjW3DocWZ?= , 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 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. Hmmm. Btw, this patch is huuuge. It would be nice if you could split it, if possible... Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --