From patchwork Wed Feb 17 15:45:10 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matt Fleming X-Patchwork-Id: 8340451 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id DAA7FC0553 for ; Wed, 17 Feb 2016 15:45:58 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id DADB9203F4 for ; Wed, 17 Feb 2016 15:45:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DB59C203B1 for ; Wed, 17 Feb 2016 15:45:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422918AbcBQPpk (ORCPT ); Wed, 17 Feb 2016 10:45:40 -0500 Received: from mail-wm0-f54.google.com ([74.125.82.54]:35889 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422917AbcBQPpQ (ORCPT ); Wed, 17 Feb 2016 10:45:16 -0500 Received: by mail-wm0-f54.google.com with SMTP id g62so166859059wme.1 for ; Wed, 17 Feb 2016 07:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeblueprint-co-uk.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=lQizCU6AKAcprGjY4Ve+Zh8lqxjIWmzGTBuC4LsOFe4=; b=Tpk3ptbnOlEZgjrihRWiTDladGgHjhNlGGtmn704CdPdzdlsUv5vgjAhHKqbC8ibYX xdXSd3PSeKwQFqTlI31lkrxfjIFVi6GSX8oNCet0Me+XC9EQ5RDv0ATpz99symWY/TVj dsB8SIs6hAzCJnCvztrwxPyHhOxlJrMeBN8MbbNAcAFQCgimWQtEnacf4/o7zBkpaAeY aqw63y0LYaUOrMN25b5yECHmrpGfRt+80oP/SGVB4nFeG5iHi/AHLNKk9xeu2ylmOtSl 71CwiKL4rXQjr0ASXd+MZWSYaS8mT8kSfD7qdFDMLojngWsGsEKQnzBdV6bLcHivuMBK pnRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=lQizCU6AKAcprGjY4Ve+Zh8lqxjIWmzGTBuC4LsOFe4=; b=lr5neYoUFP2D3YB2f6Zx20sxrVsJA9MX6IzJAj5d7vom2el6hLQTchain27NmtYuvM UxBpvenpOterQTvt8oPy++mD87Afd9hf/4OAafhOOnWJPIs2nPFNOTXIfmv8QEq5NkuH HfmWdDQVhqWjgUJF6zQDC5PLm6qMxjycKkwagtRj8X5w63l778P9w/+oXlk+/XnudR56 lukPoAz75OfL2gVnaSOeMdqZOThj51DxbKM8jRKQOnFLng3oyemJJRI5MThYv4kZZD7Y RojRPy46Ca+MIgllSCECG/3WeP24qluvNRQ/4pmKE7yNtWiPV3tIMzyqTFc24B6Rxwxp 1nzA== X-Gm-Message-State: AG10YOSVqHymXSW6UGHBhfqEV0AZDUHoIIcDMbeWAfInz+z8ZFIhbUy/0lM42i65enmYbw== X-Received: by 10.194.7.195 with SMTP id l3mr2597276wja.43.1455723914976; Wed, 17 Feb 2016 07:45:14 -0800 (PST) Received: from localhost (5ec16434.skybroadband.com. [94.193.100.52]) by smtp.gmail.com with ESMTPSA id hm9sm2069641wjb.34.2016.02.17.07.45.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Feb 2016 07:45:14 -0800 (PST) From: Matt Fleming To: Dave Young Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-acpi@vger.kernel.org, kexec@lists.infradead.org, "Rafael J . Wysocki" , Josh Triplett , Borislav Petkov , Matthew Garrett , Vivek Goyal , Matt Fleming Subject: [PATCH 2/2] x86/efi: Delete ACPI BGRT when booting via kexec Date: Wed, 17 Feb 2016 15:45:10 +0000 Message-Id: <1455723910-16710-3-git-send-email-matt@codeblueprint.co.uk> X-Mailer: git-send-email 2.6.2 In-Reply-To: <1455723910-16710-1-git-send-email-matt@codeblueprint.co.uk> References: <1455723910-16710-1-git-send-email-matt@codeblueprint.co.uk> Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Dave reports that for kexec reboot the ACPI BGRT image region may contain garbage data, because the image lives in EFI Boot Services regions that were released and freed when the first kernel called efi_free_boot_services(). Since the EFI Boot Services regions can be large (multiple gigabytes) preserving them throughout the kernel's lifetime and across kexec reboot is not a viable solution. Instead we need to avoid accessing the BGRT image regions under kexec. Rather than dirtying the ACPI BGRT driver with conditionals that check whether we're booting via kexec, we can execute the existing code path that exits if the table cannot be found - by removing the BGRT table. It is unfortunate that this logic cannot be folded into the existing kexec-specific EFI code, but there are dependencies on having loaded the ACPI tables, which happens much later. Reported-by: Dave Young Cc: Rafael J. Wysocki Cc: Josh Triplett Cc: Borislav Petkov Cc: Matthew Garrett Cc: Vivek Goyal Cc: Signed-off-by: Matt Fleming --- arch/x86/include/asm/efi.h | 1 + arch/x86/kernel/setup.c | 4 +++- arch/x86/platform/efi/efi.c | 38 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 42 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h index 7bb206f73915..0e813da58be6 100644 --- a/arch/x86/include/asm/efi.h +++ b/arch/x86/include/asm/efi.h @@ -146,6 +146,7 @@ extern void __init efi_dump_pagetable(void); extern void __init efi_apply_memmap_quirks(void); extern int __init efi_reuse_config(u64 tables, int nr_tables); extern void efi_delete_dummy_variable(void); +extern void __init efi_kexec_remove_acpi_tables(void); struct efi_setup_data { u64 fw_vendor; diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index d3d80e6d42a2..8131962ce8c2 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1249,8 +1249,10 @@ void __init setup_arch(char **cmdline_p) register_refined_jiffies(CLOCK_TICK_RATE); #ifdef CONFIG_EFI - if (efi_enabled(EFI_BOOT)) + if (efi_enabled(EFI_BOOT)) { efi_apply_memmap_quirks(); + efi_kexec_remove_acpi_tables(); + } #endif } diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 39748d228e34..d87f42697ad0 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -485,6 +485,44 @@ static int __init efi_kexec_override(void) return 0; } +/* + * The BGRT table, if present, refers to memory regions that are no + * longer reserved during kexec boot, having been released by the + * previous kernel. The BGRT image likely contains garbage. + * + * Delete the ACPI table, since it is useless for kexec, and so that + * it is impossible for the ACPI BGRT driver to distinguish between + * "Platform has no BGRT" and "We were booted via kexec". + * + * Note that this function must only be called after the ACPI tables + * have been initialised. + */ +void __init efi_kexec_remove_acpi_tables(void) +{ + struct acpi_table_header *header; + acpi_status status; + + if (!efi_setup) + return; + + status = acpi_get_table(ACPI_SIG_BGRT, 0, &header); + if (ACPI_FAILURE(status)) + return; + + status = acpi_remove_table(ACPI_SIG_BGRT, 0); + if (ACPI_FAILURE(status)) { + pr_err("Failed to remove ACPI BGRT table\n"); + return; + } + + /* + * Since we've probably already told the user that we have a + * BGRT when parsing the ACPI tables, inform them that we have + * intentionally removed it now. + */ + pr_info("Removed ACPI BGRT table for kexec\n"); +} + void __init efi_init(void) { efi_char16_t *c16;