From patchwork Sat Jan 11 09:49:49 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 206642 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64006C33C9E for ; Sat, 11 Jan 2020 10:08:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3856320880 for ; Sat, 11 Jan 2020 10:08:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578737333; bh=GKYrCZ9/aDSL9Px/0Qf08dFJn+ZicSl101ldxGOtSH8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=eQ0p9emPWAfqViNgx/j1uo6SmNxeJ96bWNaqQlvjR/3zvhKLKD/XrtXX/zNq1JitG LV2ung+EvuRwi0aoIIUttajS7VBh9hff3FiUccrfV+1q8mS1IEv6oPp6+lytPrMTFa c5s6Tt8KbyDQMZlNqdy79I1j/iHLn8eyHNcLGooA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728812AbgAKKIx (ORCPT ); Sat, 11 Jan 2020 05:08:53 -0500 Received: from mail.kernel.org ([198.145.29.99]:44232 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729148AbgAKKIw (ORCPT ); Sat, 11 Jan 2020 05:08:52 -0500 Received: from localhost (unknown [62.119.166.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 496092082E; Sat, 11 Jan 2020 10:08:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578737331; bh=GKYrCZ9/aDSL9Px/0Qf08dFJn+ZicSl101ldxGOtSH8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CWpXMHFlMo3OIiiGHunzvEWSkYu+DqJf70HS/BgHoygYwbWj7bigg9CYgKOcV1eTO lbyDOu9/uixqqT2ZMp88cqcFOy3CeeKf0V7NII3PaWT4xKwdQk0I1vSUXWG8MDEIKE 3SUXFQOMUADFMvHNkYLd91YDxXbv2t+9d5xrS+Qg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michael Weiser , Dave Young , Ard Biesheuvel , Borislav Petkov , "Eric W. Biederman" , "H. Peter Anvin" , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , kexec@lists.infradead.org, linux-efi@vger.kernel.org, Ingo Molnar , Sasha Levin Subject: [PATCH 4.14 07/62] x86/efi: Update e820 with reserved EFI boot services data to fix kexec breakage Date: Sat, 11 Jan 2020 10:49:49 +0100 Message-Id: <20200111094840.574018450@linuxfoundation.org> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200111094837.425430968@linuxfoundation.org> References: <20200111094837.425430968@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org From: Dave Young [ Upstream commit af164898482817a1d487964b68f3c21bae7a1beb ] Michael Weiser reported that he got this error during a kexec rebooting: esrt: Unsupported ESRT version 2904149718861218184. The ESRT memory stays in EFI boot services data, and it was reserved in kernel via efi_mem_reserve(). The initial purpose of the reservation is to reuse the EFI boot services data across kexec reboot. For example the BGRT image data and some ESRT memory like Michael reported. But although the memory is reserved it is not updated in the X86 E820 table, and kexec_file_load() iterates system RAM in the IO resource list to find places for kernel, initramfs and other stuff. In Michael's case the kexec loaded initramfs overwrote the ESRT memory and then the failure happened. Since kexec_file_load() depends on the E820 table being updated, just fix this by updating the reserved EFI boot services memory as reserved type in E820. Originally any memory descriptors with EFI_MEMORY_RUNTIME attribute are bypassed in the reservation code path because they are assumed as reserved. But the reservation is still needed for multiple kexec reboots, and it is the only possible case we come here thus just drop the code chunk, then everything works without side effects. On my machine the ESRT memory sits in an EFI runtime data range, it does not trigger the problem, but I successfully tested with BGRT instead. both kexec_load() and kexec_file_load() work and kdump works as well. [ mingo: Edited the changelog. ] Reported-by: Michael Weiser Tested-by: Michael Weiser Signed-off-by: Dave Young Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Eric W. Biederman Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: kexec@lists.infradead.org Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191204075233.GA10520@dhcp-128-65.nay.redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin --- arch/x86/platform/efi/quirks.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c index 5b513ccffde4..cadd7fd290fa 100644 --- a/arch/x86/platform/efi/quirks.c +++ b/arch/x86/platform/efi/quirks.c @@ -257,10 +257,6 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size) return; } - /* No need to reserve regions that will never be freed. */ - if (md.attribute & EFI_MEMORY_RUNTIME) - return; - size += addr % EFI_PAGE_SIZE; size = round_up(size, EFI_PAGE_SIZE); addr = round_down(addr, EFI_PAGE_SIZE); @@ -290,6 +286,8 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size) early_memunmap(new, new_size); efi_memmap_install(new_phys, num_entries); + e820__range_update(addr, size, E820_TYPE_RAM, E820_TYPE_RESERVED); + e820__update_table(e820_table); } /* From patchwork Sat Jan 11 09:49:51 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 206641 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38CA1C33CA3 for ; Sat, 11 Jan 2020 10:09:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0C44320882 for ; Sat, 11 Jan 2020 10:09:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578737345; bh=lNUYq7bp5wkI5mc/7OLg2R0gWlSNmXm1kqXk6M4f69k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=MmJgAQhGW94Mx9XX/By0MNRH5NIfXfVpXmRssZu335agpogx9KPKF/4Nt5shaemQw l9NrIuvK0YaHhBBJrcfrxY/zEh4JenSizxXvY7xb7eTtUUHnmVXRiOVB373ovaoDWR GD+9VHt/dZJAbdf59RnudfmP9AXQePQ2bRt1M054= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729148AbgAKKJB (ORCPT ); Sat, 11 Jan 2020 05:09:01 -0500 Received: from mail.kernel.org ([198.145.29.99]:44548 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729097AbgAKKJB (ORCPT ); Sat, 11 Jan 2020 05:09:01 -0500 Received: from localhost (unknown [62.119.166.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 03CE22084D; Sat, 11 Jan 2020 10:09:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578737340; bh=lNUYq7bp5wkI5mc/7OLg2R0gWlSNmXm1kqXk6M4f69k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vO01E+oxnulBzgNzSbVjHBFl/PHJ24jUyBzXmvitYJxuyZkcCi/+A1OnhrY/nK6h9 lpZLHo/yJMUh/oWon/iar/im16j5ARaKAnETHU0Rxn9YJ9O9jYD0RQjYBoR2tcQdsQ 5BUE1unw5/3t+ghcl+S8DpWI6dwZEusQcgKnJCUY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arvind Sankar , Ard Biesheuvel , Andy Shevchenko , Bhupesh Sharma , Masayoshi Mizuma , linux-efi@vger.kernel.org, Ingo Molnar , Sasha Levin Subject: [PATCH 4.14 09/62] efi/gop: Return EFI_SUCCESS if a usable GOP was found Date: Sat, 11 Jan 2020 10:49:51 +0100 Message-Id: <20200111094841.330769059@linuxfoundation.org> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200111094837.425430968@linuxfoundation.org> References: <20200111094837.425430968@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org From: Arvind Sankar [ Upstream commit dbd89c303b4420f6cdb689fd398349fc83b059dd ] If we've found a usable instance of the Graphics Output Protocol (GOP) with a framebuffer, it is possible that one of the later EFI calls fails while checking if any support console output. In this case status may be an EFI error code even though we found a usable GOP. Fix this by explicitly return EFI_SUCCESS if a usable GOP has been located. Signed-off-by: Arvind Sankar Signed-off-by: Ard Biesheuvel Cc: Andy Shevchenko Cc: Bhupesh Sharma Cc: Masayoshi Mizuma Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-4-ardb@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin --- drivers/firmware/efi/libstub/gop.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/efi/libstub/gop.c b/drivers/firmware/efi/libstub/gop.c index 16ed61c023e8..81ffda5d1e48 100644 --- a/drivers/firmware/efi/libstub/gop.c +++ b/drivers/firmware/efi/libstub/gop.c @@ -200,7 +200,7 @@ setup_gop32(efi_system_table_t *sys_table_arg, struct screen_info *si, si->capabilities |= VIDEO_CAPABILITY_SKIP_QUIRKS; - return status; + return EFI_SUCCESS; } static efi_status_t @@ -318,7 +318,7 @@ setup_gop64(efi_system_table_t *sys_table_arg, struct screen_info *si, si->capabilities |= VIDEO_CAPABILITY_SKIP_QUIRKS; - return status; + return EFI_SUCCESS; } /*