Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3698791pxv; Mon, 26 Jul 2021 09:40:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzqsj8Vp4b7jgqtnxKg4mGNhH9yN7wSD3uP0AqBTvpSzvyGRRjCXHi6unMwSlf0fj+llM4O X-Received: by 2002:a05:6402:b83:: with SMTP id cf3mr7397618edb.12.1627317509195; Mon, 26 Jul 2021 09:38:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627317509; cv=none; d=google.com; s=arc-20160816; b=FDdQGctUHk44xBinjstWaip+6po+/qjKbVyzJ8OTytVG7l8fferzbzoQqzw5jp7y0q LEPMnY7eZSsuZeFw+ksbnLt1o+sf24N9mbFLUcqq+emWm6hHn6sOCwr4BFN9YqGPeGhY dqCSaKYPkMk/0TB7JW8dbIO9pU+mhFZPR+0YEFY3xYJSN4Dr33A3y5/R/lkNzi2i1rKs HMSrpCy8+9nmseh4KffcovWv+qL5SvQJDoXZuCRhBeWhVSCVUcxu36c+KLZ5kBiYGr8z KDA2jV8PsMHKERiDKW0LrrgH7Yw95BDJaAmB6qtJz+8mXCEAR/kDafiAayGVoozAfTiX VUCg== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=4/OwTwjTpToNf8f56RuXy8KKqxxKf3rFf6efqIsgsSs=; b=C6f4hg+wVxw57gMcrrzQnifL/tno8RKDUM5EtnYLWHDfQVFX4oXM+Khl3dnq366LwV y11S74Rj/D/BV5rPpI+PWV9nH3UzRUiCKRCGniI6lT3nMkn+rBykOsOx4KyV14PXauEX gophIvT8fCznFcRIXZeuTyos8EhpVAcixpKML0ojo6XCR8kH2bt9OJJamlBTW0VhL25+ q/OWAwvw4nfbSQtJfUFHNVTLzsrHRloLXZi71j891/CfQnGJ0ieL32H+3WzTcD/wKFhT bH6NLBkNES96vk/N5U/YGdIOtE4WV9V/caHZM9u2QByAFsTeEslW+TLIWjJicSlb+QV5 ywaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=txfTI6xJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z15si377284ejr.728.2021.07.26.09.38.05; Mon, 26 Jul 2021 09:38:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=txfTI6xJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239997AbhGZPyq (ORCPT + 99 others); Mon, 26 Jul 2021 11:54:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:51048 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235038AbhGZPeE (ORCPT ); Mon, 26 Jul 2021 11:34:04 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id EB45260C41; Mon, 26 Jul 2021 16:14:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1627316072; bh=DwyVYqiMRT2XLPZyNrzr6ANXv+Xakn1sUDBI6YVzpXQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=txfTI6xJy+XrjUZClvGDJTDz0kCKY4dgI4XSvvHCNmE5oTLdIaVbmIvy8tkNSd8Tv 7XVAuM1azyds9CT3PhqrBTBSQtLQF95Yjkj2Ex+RKB/Vkm/WwSJ3sBdENQp0okoyGN 4TSACyZSJIUXco5vSf4nwVW4e9f83xZ9OsBs9BA0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Moritz Fischer , Marc Zyngier , Ard Biesheuvel , James Morse , Catalin Marinas , Will Deacon Subject: [PATCH 5.13 176/223] firmware/efi: Tell memblock about EFI iomem reservations Date: Mon, 26 Jul 2021 17:39:28 +0200 Message-Id: <20210726153851.956064385@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210726153846.245305071@linuxfoundation.org> References: <20210726153846.245305071@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Marc Zyngier commit 2bab693a608bdf614b9fcd44083c5100f34b9f77 upstream. kexec_load_file() relies on the memblock infrastructure to avoid stamping over regions of memory that are essential to the survival of the system. However, nobody seems to agree how to flag these regions as reserved, and (for example) EFI only publishes its reservations in /proc/iomem for the benefit of the traditional, userspace based kexec tool. On arm64 platforms with GICv3, this can result in the payload being placed at the location of the LPI tables. Shock, horror! Let's augment the EFI reservation code with a memblock_reserve() call, protecting our dear tables from the secondary kernel invasion. Reported-by: Moritz Fischer Tested-by: Moritz Fischer Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Cc: Ard Biesheuvel Cc: James Morse Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman --- drivers/firmware/efi/efi.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -896,6 +896,7 @@ static int __init efi_memreserve_map_roo static int efi_mem_reserve_iomem(phys_addr_t addr, u64 size) { struct resource *res, *parent; + int ret; res = kzalloc(sizeof(struct resource), GFP_ATOMIC); if (!res) @@ -908,7 +909,17 @@ static int efi_mem_reserve_iomem(phys_ad /* we expect a conflict with a 'System RAM' region */ parent = request_resource_conflict(&iomem_resource, res); - return parent ? request_resource(parent, res) : 0; + ret = parent ? request_resource(parent, res) : 0; + + /* + * Given that efi_mem_reserve_iomem() can be called at any + * time, only call memblock_reserve() if the architecture + * keeps the infrastructure around. + */ + if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK) && !ret) + memblock_reserve(addr, size); + + return ret; } int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)