From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751882AbdG1Kcn (ORCPT ); Fri, 28 Jul 2017 06:32:43 -0400 Received: from mx2.suse.de ([195.135.220.15]:51889 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751690AbdG1Kck (ORCPT ); Fri, 28 Jul 2017 06:32:40 -0400 Date: Fri, 28 Jul 2017 12:31:52 +0200 From: Borislav Petkov To: Brijesh Singh Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-efi@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Andy Lutomirski , Tony Luck , Piotr Luc , Tom Lendacky , Fenghua Yu , Lu Baolu , Reza Arbab , David Howells , Matt Fleming , "Kirill A . Shutemov" , Laura Abbott , Ard Biesheuvel , Andrew Morton , Eric Biederman , Benjamin Herrenschmidt , Paul Mackerras , Konrad Rzeszutek Wilk , Jonathan Corbet , Dave Airlie , Kees Cook , Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , Arnd Bergmann , Tejun Heo , Christoph Lameter Subject: Re: [RFC Part1 PATCH v3 08/17] x86/efi: Access EFI data as encrypted when SEV is active Message-ID: <20170728103152.GE1889@nazgul.tnic> References: <20170724190757.11278-1-brijesh.singh@amd.com> <20170724190757.11278-9-brijesh.singh@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170724190757.11278-9-brijesh.singh@amd.com> 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, Jul 24, 2017 at 02:07:48PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > EFI data is encrypted when the kernel is run under SEV. Update the > page table references to be sure the EFI memory areas are accessed > encrypted. > > Signed-off-by: Tom Lendacky > Signed-off-by: Brijesh Singh > --- > arch/x86/platform/efi/efi_64.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c > index 12e8388..1ecb3f6 100644 > --- a/arch/x86/platform/efi/efi_64.c > +++ b/arch/x86/platform/efi/efi_64.c > @@ -32,6 +32,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -369,7 +370,10 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages) > * as trim_bios_range() will reserve the first page and isolate it away > * from memory allocators anyway. > */ > - if (kernel_map_pages_in_pgd(pgd, 0x0, 0x0, 1, _PAGE_RW)) { > + pf = _PAGE_RW; > + if (sev_active()) > + pf |= _PAGE_ENC; \n here > + if (kernel_map_pages_in_pgd(pgd, 0x0, 0x0, 1, pf)) { > pr_err("Failed to create 1:1 mapping for the first page!\n"); > return 1; > } > @@ -412,6 +416,9 @@ static void __init __map_region(efi_memory_desc_t *md, u64 va) > if (!(md->attribute & EFI_MEMORY_WB)) > flags |= _PAGE_PCD; > > + if (sev_active()) > + flags |= _PAGE_ENC; > + > pfn = md->phys_addr >> PAGE_SHIFT; > if (kernel_map_pages_in_pgd(pgd, pfn, va, md->num_pages, flags)) > pr_warn("Error mapping PA 0x%llx -> VA 0x%llx!\n", > @@ -511,6 +518,9 @@ static int __init efi_update_mappings(efi_memory_desc_t *md, unsigned long pf) > pgd_t *pgd = efi_pgd; > int err1, err2; > > + if (sev_active()) > + pf |= _PAGE_ENC; Move this assignment to the caller efi_update_mem_attr() where pf is being set... > + > /* Update the 1:1 mapping */ > pfn = md->phys_addr >> PAGE_SHIFT; > err1 = kernel_map_pages_in_pgd(pgd, pfn, md->phys_addr, md->num_pages, pf); > @@ -589,6 +599,9 @@ void __init efi_runtime_update_mappings(void) > (md->type != EFI_RUNTIME_SERVICES_CODE)) > pf |= _PAGE_RW; > > + if (sev_active()) > + pf |= _PAGE_ENC; ... just like here. > + > efi_update_mappings(md, pf); In general, I'm not totally excited about that sprinkling of if (sev_active())... :-\ -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --