From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933536AbcFQPvy (ORCPT ); Fri, 17 Jun 2016 11:51:54 -0400 Received: from mail-wm0-f50.google.com ([74.125.82.50]:37888 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755369AbcFQPvt (ORCPT ); Fri, 17 Jun 2016 11:51:49 -0400 Date: Fri, 17 Jun 2016 16:51:45 +0100 From: Matt Fleming 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 , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov Subject: Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear Message-ID: <20160617155145.GJ2658@codeblueprint.co.uk> References: <20160426225553.13567.19459.stgit@tlendack-t1.amdoffice.net> <20160426225740.13567.85438.stgit@tlendack-t1.amdoffice.net> <20160608111844.GV2658@codeblueprint.co.uk> <5759B67A.4000800@amd.com> <20160613135110.GC2658@codeblueprint.co.uk> <57615561.4090502@amd.com> <5762B9E7.80903@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5762B9E7.80903@amd.com> User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 16 Jun, at 09:38:31AM, Tom Lendacky wrote: > > Ok, I think this was happening before the commit to build our own > EFI page table structures: > > commit 67a9108ed ("x86/efi: Build our own page table structures") > > Before this commit the boot services ended up mapped into the kernel > page table entries as un-encrypted during efi_map_regions() and I needed > to change those entries back to encrypted. With your change above, > this appears to no longer be needed. Great news! Things are as they should be ;)