Message ID | dab948690a74db1bb75d95aa7e0362deeca6dbf4.1678785672.git.baskov@ispras.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1672864wrd; Tue, 14 Mar 2023 03:23:53 -0700 (PDT) X-Google-Smtp-Source: AK7set+LtMBv1uLmjnpwBPz4Wk1V9GnBS942pXb3B6mglCwR9C+QmeGy22MsIo8LRzYe2wSWKSDp X-Received: by 2002:a17:903:1cb:b0:19e:f647:6075 with SMTP id e11-20020a17090301cb00b0019ef6476075mr14393802plh.27.1678789432709; Tue, 14 Mar 2023 03:23:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1678789432; cv=none; d=google.com; s=arc-20160816; b=DhpcSBy/Leoi6fetmX4jtKDKFbb0bzqruwgV2kgXi5AUJJSChP2IEdmd1ieqE+hxWG Z1Ata+nnkEAPWZ40ST6BEXJOo/jmmwxJj9xnAOIP1dDtRrA7lzGfZGgCRmL9aosfeCPL S3MvOPuOIk9cqks5RetsMndYkcPop/1PbD6ikPgT7JLdUpocmUNejb9V71rE1qWak2IS jToOKpj40H+6ZXfTM4/SBQDBDv9/uhP+8Ky5WEZXOXSXzVElRkHLwQg1Vqgi3OVpsiiq jU5q314I1ARZhRQJurnTtqSMDD8vNSroXMKA+IIC+avZY0MjGGYs8zdvYv4LB4kXWDGF tROw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:dkim-filter; bh=KQX50IDaA6jZ2kthtK8SXDuugyihF8jwWgQGjoDSXQ0=; b=hQax38JYTEdEZnQB0cAc/f3Fxw3nuc524t2I/1kEIVzoaRmjMYtWwZJOlV9xvqFPM/ MaCqllg0ybPkbI82/vV2DcsExOXEim8EeEPB2lmakJdKjO0/lsDrVLbij4cTfWCQiyUZ 5zoUwgNS63znHtMED+J6wLzIPsy7SYRVC7yS73bgGCXhW1jWZa649oyj83/mX8TZ5Pn/ mppP5h8PpXrNoOntF0xVdmCs+ZM4ti7x7CpNDI4i1lV71rdkgfBvvhPQEuJdYoQ3lewx 9il8dgoWYLDZWByFYYB2jkiaN/kpV1DTGUpEhNTKX33ji62Xxqb3Gf2wORRl2tV6OPcF WgyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ispras.ru header.s=default header.b=KjQYisjf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ko5-20020a17090307c500b001a05bb13953si599573plb.422.2023.03.14.03.23.38; Tue, 14 Mar 2023 03:23:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ispras.ru header.s=default header.b=KjQYisjf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231131AbjCNKRA (ORCPT <rfc822;realc9580@gmail.com> + 99 others); Tue, 14 Mar 2023 06:17:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39206 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230445AbjCNKQe (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Mar 2023 06:16:34 -0400 Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3AED392F0C; Tue, 14 Mar 2023 03:16:04 -0700 (PDT) Received: from localhost.localdomain (unknown [83.149.199.65]) by mail.ispras.ru (Postfix) with ESMTPSA id 759B94076B51; Tue, 14 Mar 2023 10:16:02 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 759B94076B51 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1678788962; bh=KQX50IDaA6jZ2kthtK8SXDuugyihF8jwWgQGjoDSXQ0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KjQYisjfZxZMV6h4m+SHY/QIVeA5iWeLKlreyZ85e4KK9cIyEmIPmZQyE654zZ1CU m61kYU1rLJ4noPb5EZpmpeIFyD6fr/Q0K/v9kn1xDsZsxdwDVjBj+DQAIzYG/Y7hhe wSsXQ2o3Afrd6yrxTnu+4zpucAJtk+9SLq9+olis= From: Evgeniy Baskov <baskov@ispras.ru> To: Ard Biesheuvel <ardb@kernel.org> Cc: Evgeniy Baskov <baskov@ispras.ru>, Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>, Dave Hansen <dave.hansen@linux.intel.com>, Ingo Molnar <mingo@redhat.com>, Peter Zijlstra <peterz@infradead.org>, Thomas Gleixner <tglx@linutronix.de>, Alexey Khoroshilov <khoroshilov@ispras.ru>, Peter Jones <pjones@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, "Limonciello, Mario" <mario.limonciello@amd.com>, joeyli <jlee@suse.com>, lvc-project@linuxtesting.org, x86@kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: [PATCH v5 09/27] x86/boot: Remove mapping from page fault handler Date: Tue, 14 Mar 2023 13:13:36 +0300 Message-Id: <dab948690a74db1bb75d95aa7e0362deeca6dbf4.1678785672.git.baskov@ispras.ru> X-Mailer: git-send-email 2.39.2 In-Reply-To: <cover.1678785672.git.baskov@ispras.ru> References: <cover.1678785672.git.baskov@ispras.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760338307794289402?= X-GMAIL-MSGID: =?utf-8?q?1760338307794289402?= |
Series |
x86_64: Improvements at compressed kernel stage
|
|
Commit Message
Evgeniy Baskov
March 14, 2023, 10:13 a.m. UTC
After every implicit mapping is removed, this code is no longer needed. Remove memory mapping from page fault handler to ensure that there are no hidden invalid memory accesses. Tested-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Evgeniy Baskov <baskov@ispras.ru> --- arch/x86/boot/compressed/ident_map_64.c | 26 ++++++++++--------------- 1 file changed, 10 insertions(+), 16 deletions(-)
Comments
On Tue, Mar 14, 2023, at 3:13 AM, Evgeniy Baskov wrote: > After every implicit mapping is removed, this code is no longer needed. > > Remove memory mapping from page fault handler to ensure that there are > no hidden invalid memory accesses. This patch is *by far* the scariest of the bunch in my boot. And it violates a basic principle of kernel development: it's better to run in degraded mode than to fail outright unless running in degraded mode is dangerous for some reason. And this boot code is not actually meaningfully exposed to attack. Anyone who can get the boot code to consume garbage likely *already* controls the system, including anything that we might write to TPM or any other verification mechanism. So I think this should log an error, set a flag to make sure we print an even louder error after full boot, but still add the mapping and keep trying. --Andy > > Tested-by: Mario Limonciello <mario.limonciello@amd.com> > Signed-off-by: Evgeniy Baskov <baskov@ispras.ru> > --- > arch/x86/boot/compressed/ident_map_64.c | 26 ++++++++++--------------- > 1 file changed, 10 insertions(+), 16 deletions(-) > > diff --git a/arch/x86/boot/compressed/ident_map_64.c > b/arch/x86/boot/compressed/ident_map_64.c > index eb28ce9812c5..378f99b1d7e8 100644 > --- a/arch/x86/boot/compressed/ident_map_64.c > +++ b/arch/x86/boot/compressed/ident_map_64.c > @@ -393,27 +393,21 @@ void do_boot_page_fault(struct pt_regs *regs, > unsigned long error_code) > { > unsigned long address = native_read_cr2(); > unsigned long end; > - bool ghcb_fault; > + char *msg; > > - ghcb_fault = sev_es_check_ghcb_fault(address); > + if (sev_es_check_ghcb_fault(address)) > + msg = "Page-fault on GHCB page:"; > + else > + msg = "Unexpected page-fault:"; > > address &= PMD_MASK; > end = address + PMD_SIZE; > > /* > - * Check for unexpected error codes. Unexpected are: > - * - Faults on present pages > - * - User faults > - * - Reserved bits set > - */ > - if (error_code & (X86_PF_PROT | X86_PF_USER | X86_PF_RSVD)) > - do_pf_error("Unexpected page-fault:", error_code, address, regs->ip); > - else if (ghcb_fault) > - do_pf_error("Page-fault on GHCB page:", error_code, address, regs->ip); > - > - /* > - * Error code is sane - now identity map the 2M region around > - * the faulting address. > + * Since all memory allocations are made explicit > + * now, every page fault at this stage is an > + * error and the error handler is there only > + * for debug purposes. > */ > - kernel_add_identity_map(address, end, MAP_WRITE); > + do_pf_error(msg, error_code, address, regs->ip); > } > -- > 2.39.2
On 2023-03-14 23:33, Andy Lutomirski wrote: > On Tue, Mar 14, 2023, at 3:13 AM, Evgeniy Baskov wrote: >> After every implicit mapping is removed, this code is no longer >> needed. >> >> Remove memory mapping from page fault handler to ensure that there are >> no hidden invalid memory accesses. > > This patch is *by far* the scariest of the bunch in my boot. And it > violates a basic principle of kernel development: it's better to run > in degraded mode than to fail outright unless running in degraded mode > is dangerous for some reason. > > And this boot code is not actually meaningfully exposed to attack. > Anyone who can get the boot code to consume garbage likely *already* > controls the system, including anything that we might write to TPM or > any other verification mechanism. > > So I think this should log an error, set a flag to make sure we print > an even louder error after full boot, but still add the mapping and > keep trying. Good point. This patch can be dropped and replaced by the loud warning, since it is not required for the functioning of the rest of the series it is here mainly to indicate bugs in the kernel rather than for the increased protection. But I would not expect anything in the working systems, I made my best to map all the things explicitly. And since no code but the extraction code is supposed to be run (interrupts are disabled and we are not using any UEFI services there), this should be practically save to remove the implicit mapping. And at least this allowed me to find out about the insufficient size of the boot page tables which did not account for the ACPI and UEFI mappings. (patch 4 "x86/boot: Increase boot page table size") If this patch is dropped now, I can send the follow up patch later adding the warning. Thanks, Evgeniy Baskov > > --Andy > >> >> Tested-by: Mario Limonciello <mario.limonciello@amd.com> >> Signed-off-by: Evgeniy Baskov <baskov@ispras.ru> >> --- >> arch/x86/boot/compressed/ident_map_64.c | 26 >> ++++++++++--------------- >> 1 file changed, 10 insertions(+), 16 deletions(-) >> ...
diff --git a/arch/x86/boot/compressed/ident_map_64.c b/arch/x86/boot/compressed/ident_map_64.c index eb28ce9812c5..378f99b1d7e8 100644 --- a/arch/x86/boot/compressed/ident_map_64.c +++ b/arch/x86/boot/compressed/ident_map_64.c @@ -393,27 +393,21 @@ void do_boot_page_fault(struct pt_regs *regs, unsigned long error_code) { unsigned long address = native_read_cr2(); unsigned long end; - bool ghcb_fault; + char *msg; - ghcb_fault = sev_es_check_ghcb_fault(address); + if (sev_es_check_ghcb_fault(address)) + msg = "Page-fault on GHCB page:"; + else + msg = "Unexpected page-fault:"; address &= PMD_MASK; end = address + PMD_SIZE; /* - * Check for unexpected error codes. Unexpected are: - * - Faults on present pages - * - User faults - * - Reserved bits set - */ - if (error_code & (X86_PF_PROT | X86_PF_USER | X86_PF_RSVD)) - do_pf_error("Unexpected page-fault:", error_code, address, regs->ip); - else if (ghcb_fault) - do_pf_error("Page-fault on GHCB page:", error_code, address, regs->ip); - - /* - * Error code is sane - now identity map the 2M region around - * the faulting address. + * Since all memory allocations are made explicit + * now, every page fault at this stage is an + * error and the error handler is there only + * for debug purposes. */ - kernel_add_identity_map(address, end, MAP_WRITE); + do_pf_error(msg, error_code, address, regs->ip); }