From patchwork Mon Feb 20 19:45:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Borislav Petkov X-Patchwork-Id: 9583551 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id F14776047C for ; Mon, 20 Feb 2017 19:46:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E556328878 for ; Mon, 20 Feb 2017 19:46:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D6EA728876; Mon, 20 Feb 2017 19:46:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3559F28422 for ; Mon, 20 Feb 2017 19:46:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751457AbdBTTp7 (ORCPT ); Mon, 20 Feb 2017 14:45:59 -0500 Received: from mail.skyhub.de ([78.46.96.112]:34732 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751100AbdBTTp6 (ORCPT ); Mon, 20 Feb 2017 14:45:58 -0500 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aYqUtsetUAWY; Mon, 20 Feb 2017 20:45:54 +0100 (CET) Received: from pd.tnic (p2003008C2F243000815F177A93DCDD87.dip0.t-ipconnect.de [IPv6:2003:8c:2f24:3000:815f:177a:93dc:dd87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id DC8241DA2B8; Mon, 20 Feb 2017 20:45:53 +0100 (CET) Received: by pd.tnic (Postfix, from userid 1000) id 836D916043E; Mon, 20 Feb 2017 20:45:29 +0100 (CET) Date: Mon, 20 Feb 2017 20:45:29 +0100 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, Rik van Riel , Radim =?utf-8?B?S3LEjW3DocWZ?= , Toshimitsu Kani , Arnd Bergmann , Jonathan Corbet , Matt Fleming , "Michael S. Tsirkin" , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Brijesh Singh , Ingo Molnar , Alexander Potapenko , Andy Lutomirski , "H. Peter Anvin" , Andrey Ryabinin , Thomas Gleixner , Larry Woodman , Dmitry Vyukov Subject: Re: [RFC PATCH v4 10/28] x86: Insure that boot memory areas are mapped properly Message-ID: <20170220194529.7dekuruclq7hfyhk@pd.tnic> References: <20170216154158.19244.66630.stgit@tlendack-t1.amdoffice.net> <20170216154411.19244.99258.stgit@tlendack-t1.amdoffice.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170216154411.19244.99258.stgit@tlendack-t1.amdoffice.net> User-Agent: NeoMutt/20170113 (1.7.2) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, Feb 16, 2017 at 09:44:11AM -0600, Tom Lendacky wrote: > The boot data and command line data are present in memory in a decrypted > state and are copied early in the boot process. The early page fault > support will map these areas as encrypted, so before attempting to copy > them, add decrypted mappings so the data is accessed properly when copied. > > For the initrd, encrypt this data in place. Since the future mapping of the > initrd area will be mapped as encrypted the data will be accessed properly. > > Signed-off-by: Tom Lendacky > --- ... > diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c > index 182a4c7..03f8e74 100644 > --- a/arch/x86/kernel/head64.c > +++ b/arch/x86/kernel/head64.c > @@ -46,13 +46,18 @@ static void __init reset_early_page_tables(void) > write_cr3(__sme_pa_nodebug(early_level4_pgt)); > } > > +void __init __early_pgtable_flush(void) > +{ > + write_cr3(__sme_pa_nodebug(early_level4_pgt)); > +} Move that to mem_encrypt.c where it is used and make it static. The diff below, ontop of this patch, seems to build fine here. Also, aren't those mappings global so that you need to toggle CR4.PGE for that? PAGE_KERNEL at least has _PAGE_GLOBAL set. > + > /* Create a new PMD entry */ > -int __init early_make_pgtable(unsigned long address) > +int __init __early_make_pgtable(unsigned long address, pmdval_t pmd) __early_make_pmd() then, since it creates a PMD entry. > unsigned long physaddr = address - __PAGE_OFFSET; > pgdval_t pgd, *pgd_p; > pudval_t pud, *pud_p; > - pmdval_t pmd, *pmd_p; > + pmdval_t *pmd_p; > > /* Invalid address or early pgt is done ? */ > if (physaddr >= MAXMEM || read_cr3() != __sme_pa_nodebug(early_level4_pgt)) ... > diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c > index ac3565c..ec548e9 100644 > --- a/arch/x86/mm/mem_encrypt.c > +++ b/arch/x86/mm/mem_encrypt.c > @@ -16,8 +16,12 @@ > > #include > #include > +#include > +#include > > extern pmdval_t early_pmd_flags; > +int __init __early_make_pgtable(unsigned long, pmdval_t); > +void __init __early_pgtable_flush(void); What's with the forward declarations? Those should be in some header AFAICT. > * Since SME related variables are set early in the boot process they must > @@ -103,6 +107,76 @@ void __init sme_early_decrypt(resource_size_t paddr, unsigned long size) > __sme_early_enc_dec(paddr, size, false); > } ... diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c index 03f8e74c7223..c47500d72330 100644 --- a/arch/x86/kernel/head64.c +++ b/arch/x86/kernel/head64.c @@ -46,11 +46,6 @@ static void __init reset_early_page_tables(void) write_cr3(__sme_pa_nodebug(early_level4_pgt)); } -void __init __early_pgtable_flush(void) -{ - write_cr3(__sme_pa_nodebug(early_level4_pgt)); -} - /* Create a new PMD entry */ int __init __early_make_pgtable(unsigned long address, pmdval_t pmd) { diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c index ec548e9a76f1..0af020b36232 100644 --- a/arch/x86/mm/mem_encrypt.c +++ b/arch/x86/mm/mem_encrypt.c @@ -21,7 +21,7 @@ extern pmdval_t early_pmd_flags; int __init __early_make_pgtable(unsigned long, pmdval_t); -void __init __early_pgtable_flush(void); +extern pgd_t early_level4_pgt[PTRS_PER_PGD]; /* * Since SME related variables are set early in the boot process they must @@ -34,6 +34,11 @@ EXPORT_SYMBOL_GPL(sme_me_mask); /* Buffer used for early in-place encryption by BSP, no locking needed */ static char sme_early_buffer[PAGE_SIZE] __aligned(PAGE_SIZE); +static void __init early_pgtable_flush(void) +{ + write_cr3(__sme_pa_nodebug(early_level4_pgt)); +} + /* * This routine does not change the underlying encryption setting of the * page(s) that map this memory. It assumes that eventually the memory is @@ -158,7 +163,7 @@ void __init sme_unmap_bootdata(char *real_mode_data) */ __sme_map_unmap_bootdata(real_mode_data, false); - __early_pgtable_flush(); + early_pgtable_flush(); } void __init sme_map_bootdata(char *real_mode_data) @@ -174,7 +179,7 @@ void __init sme_map_bootdata(char *real_mode_data) */ __sme_map_unmap_bootdata(real_mode_data, true); - __early_pgtable_flush(); + early_pgtable_flush(); } void __init sme_early_init(void)