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 >