From patchwork Mon Jul 9 23:42:26 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 141494 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp3205046ljj; Mon, 9 Jul 2018 16:42:06 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeBioWE1Ib8u3LV2BDzavwaKDyxeOAjH8scwBWm0ywPchdD5ok+E8vujhzkvzG4TQAk2QzZ X-Received: by 2002:a63:7a43:: with SMTP id j3-v6mr20347565pgn.363.1531179726435; Mon, 09 Jul 2018 16:42:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531179726; cv=none; d=google.com; s=arc-20160816; b=XVtiwV4ZYxDlUiY8qCcQIOLiFVxbIqcQsWfHAwQH/KnSl0hIjMSTcsv99xwl5TllMy YwgXTrOA58cHLHFOIk8xgsTBSlO/bgWVgIzjupAUHcBG97OQRx8J9hlnrwkydhFQ6OGP 5uEpWCd6Ma9JEbh6/Rd1q5vSF6kJZQPGHomMP6SG7WB08kgL+TQtu7kDowQoX515AJlL 4HOFiDwPoesjuhrxa+WKS8V4+OdErpQ7q0AP5E7Xj1H1z5Nies/Sypjj5b5sR3Z6n6cM n/7tHDt8q1mgokRLF93yllU7XDSonXSd7lHpgxxwft7W133k85JfJJrD5kRaO7SKopcf Vctw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=F9qL97WIJTDKar0RATFRGa32DomSlp6yFEb0hpSLUU4=; b=xWk4nI6SgaPhn5nAbrSn5bYcBmTozs0mxvA0E3VaHdhxMDq5DEQLgONoOQqJG4xQSY 3kFWU+FVLAyHn3cfbTN0+xWW9XsKzEaHhLn4yviKlBAWqA/J0JQBcNvRthkTtgkTtCYe by7l/tNyaPwMU9PXrNhtu6aop6A7x+olFsT3DxZjwgQojpOouBT7eXl+3P0pSlbf4+EW akYDqTDtr1xyGtXF/NnpIZ6AFkywGQxOBqhO1WdS0SCqycTDdaMgepq9T0O6w0Se1tgM ebGMrkDUo8zE3h5ZhoZBqmZ3tDTvBad8xX2wax0Cxt7lbFOvtbzJ0pRePuY0xqPlnXnP UYjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=J1Dty9bw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i7-v6si14951295plt.433.2018.07.09.16.42.06; Mon, 09 Jul 2018 16:42:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=J1Dty9bw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933308AbeGIXmB (ORCPT + 12 others); Mon, 9 Jul 2018 19:42:01 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:36883 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932828AbeGIXl6 (ORCPT ); Mon, 9 Jul 2018 19:41:58 -0400 Received: by mail-pf0-f195.google.com with SMTP id x10-v6so4877008pfm.4 for ; Mon, 09 Jul 2018 16:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=F9qL97WIJTDKar0RATFRGa32DomSlp6yFEb0hpSLUU4=; b=J1Dty9bw2HvCVfptzhJ9j8KLnWlRTwnijOhMp450puPL/2G67C/ERCCXxZPpkxxm+1 LMoIhzNZ27yFwI2P13mSpt5Yq3i5POgS6g/MpBdbeTZFrrYbmxdUb3vP7Aoni52lcTX6 c6Qu7HJFEjPkR8prUqtzb8ve000CgswW3QiH4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=F9qL97WIJTDKar0RATFRGa32DomSlp6yFEb0hpSLUU4=; b=fy3xtajy6Nz3aKrBXz/WozULxHrTeuxHEj4Olfd+1J2gaSO4lVdZLAGAg0dZFDlGik UwqYabiR2gRrvfYuZj5pNhOGn37JB8zgJfWeZ/3mUuYdNewMdsVguZJN7yC3KEDxYC+/ IhESRFu1KczGY5aNCJqAvQT2gl2aKvnZ8gKVWICkLq2spnpPncwXGTObAUtDxlDweoik hCLhFmnhNa+9KQCmBq4nABz/4wDvoDu+IQ4Uk2Y8mVSq/tNRo8owRZzqJWDh1/G7GTq+ QB3LVQqRlso5RBjmtdi0JMwPRwIM/xvktnKznxvTeGdKYdWw3zfVCA3pR2R8F9Anf0ji jo7w== X-Gm-Message-State: APt69E3P2LKwzmNp3LDnhStUb4/SYQAzNQCL3WygSgY77uBGIFdm4unW N2wowZuXw8zTABouAxM4Rkb1BA== X-Received: by 2002:a65:520c:: with SMTP id o12-v6mr20734470pgp.15.1531179717516; Mon, 09 Jul 2018 16:41:57 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id p73-v6sm40364523pfa.142.2018.07.09.16.41.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 16:41:56 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, ard.biesheuvel@linaro.org Cc: tbaicar@codeaurora.org, bhsharma@redhat.com, dyoung@redhat.com, james.morse@arm.com, mark.rutland@arm.com, al.stone@linaro.org, graeme.gregory@linaro.org, hanjun.guo@linaro.org, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org Subject: [PATCH v3.1 1/4] arm64: export memblock_reserve()d regions via /proc/iomem Date: Tue, 10 Jul 2018 08:42:26 +0900 Message-Id: <20180709234229.20181-2-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180709234229.20181-1-takahiro.akashi@linaro.org> References: <20180709234229.20181-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: James Morse There has been some confusion around what is necessary to prevent kexec overwriting important memory regions. memblock: reserve, or nomap? Only memblock nomap regions are reported via /proc/iomem, kexec's user-space doesn't know about memblock_reserve()d regions. Until commit f56ab9a5b73ca ("efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP") the ACPI tables were nomap, now they are reserved and thus possible for kexec to overwrite with the new kernel or initrd. But this was always broken, as the UEFI memory map is also reserved and not marked as nomap. Exporting both nomap and reserved memblock types is a nuisance as they live in different memblock structures which we can't walk at the same time. Take a second walk over memblock.reserved and add new 'reserved' subnodes for the memblock_reserved() regions that aren't already described by the existing code. (e.g. Kernel Code) We use reserve_region_with_split() to find the gaps in existing named regions. This handles the gap between 'kernel code' and 'kernel data' which is memblock_reserve()d, but already partially described by request_standard_resources(). e.g.: | 80000000-dfffffff : System RAM | 80080000-80ffffff : Kernel code | 81000000-8158ffff : reserved | 81590000-8237efff : Kernel data | a0000000-dfffffff : Crash kernel | e00f0000-f949ffff : System RAM reserve_region_with_split needs kzalloc() which isn't available when request_standard_resources() is called, use an initcall. Reported-by: Bhupesh Sharma Reported-by: Tyler Baicar Suggested-by: Akashi Takahiro Signed-off-by: James Morse Fixes: d28f6df1305a ("arm64/kexec: Add core kexec support") Reviewed-by: Ard Biesheuvel CC: Mark Rutland --- arch/arm64/kernel/setup.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) -- 2.17.0 diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index 30ad2f085d1f..5b4fac434c84 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -241,6 +241,44 @@ static void __init request_standard_resources(void) } } +static int __init reserve_memblock_reserved_regions(void) +{ + phys_addr_t start, end, roundup_end = 0; + struct resource *mem, *res; + u64 i; + + for_each_reserved_mem_region(i, &start, &end) { + if (end <= roundup_end) + continue; /* done already */ + + start = __pfn_to_phys(PFN_DOWN(start)); + end = __pfn_to_phys(PFN_UP(end)) - 1; + roundup_end = end; + + res = kzalloc(sizeof(*res), GFP_ATOMIC); + if (WARN_ON(!res)) + return -ENOMEM; + res->start = start; + res->end = end; + res->name = "reserved"; + res->flags = IORESOURCE_MEM; + + mem = request_resource_conflict(&iomem_resource, res); + /* + * We expected memblock_reserve() regions to conflict with + * memory created by request_standard_resources(). + */ + if (WARN_ON_ONCE(!mem)) + continue; + kfree(res); + + reserve_region_with_split(mem, start, end, "reserved"); + } + + return 0; +} +arch_initcall(reserve_memblock_reserved_regions); + u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID }; void __init setup_arch(char **cmdline_p) From patchwork Mon Jul 9 23:42:27 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 141495 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp3205174ljj; Mon, 9 Jul 2018 16:42:19 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdfHvnYMOtgD6xdH4km6GB7UzPYkTJaLLQIyFcArscLaSRNm89kAPvhaczl4al7tFJiriY9 X-Received: by 2002:a17:902:9a08:: with SMTP id v8-v6mr22620380plp.148.1531179739300; Mon, 09 Jul 2018 16:42:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531179739; cv=none; d=google.com; s=arc-20160816; b=OGMVsY7SqdpdNY+yA/LxyzQXK7hizy4Y0dk51qcRcRM/A3xpiz44vqYVtVVX4+EHXQ Tm2EhA0VqriaYtOp2UrJja8gEeDrUtZiadVbWhnuGeEtaQBVNsd/lHqgYCXQqUJmOJZN 650tmSxxbZvyhjWF6XflXJv9GX4SodubiFD0qKsojSeppL8E6WS6JLBHnQSqvIxgimv3 +KzJkke6EcRHF2tIwRnqeE+QZQPbxNS3jbTlUB/gpnvR9HdoqG/nHtVGZlyoAHHUeXnG qbYNg0f8T5kHhImEvxaM0UyNTpphRYvZeg2hTp19TBG8c3EkNOQ82TRB2YLDaXycD1nN FMsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=G2uAeoq4DfhThX9UGnhckbXMfikniIsoGM7JqtwAgeE=; b=bztaHEAET4/GcgUw++/2kZTTPHk4ThK33D407uMlfG1n5dApEcDi9f8Yo7MTdn/XWn wCmrJ/Z7d2tZD/9r0Ds9BvQzrLr1lGaczt/78+O0U/RqOC9icDamrotQn/UzpWC6Hzjc TcWKpHa9bfxyjygn9WxgyMhal+mmmCjOL1o3Qzv5gHebVzKdYrQiySRmaED/QmwOsHiR okG43zEbFI2DOdSRgZur/7f7Ox4TlOX/p/u9dZogGAfh7L5xLZtW83ZZ9Xxu9vcnuglH 2Nx/YIHZCJub0yxWkR4kbwjmrMJXIRg8+VoP+iaL2z6V++PdEFBMpuBX3GREXcj6WbXZ oNUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=BlhWdrQd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v4-v6si15510269pfm.151.2018.07.09.16.42.19; Mon, 09 Jul 2018 16:42:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=BlhWdrQd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933379AbeGIXmN (ORCPT + 12 others); Mon, 9 Jul 2018 19:42:13 -0400 Received: from mail-pl0-f65.google.com ([209.85.160.65]:41477 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933313AbeGIXmI (ORCPT ); Mon, 9 Jul 2018 19:42:08 -0400 Received: by mail-pl0-f65.google.com with SMTP id w8-v6so6732605ply.8 for ; Mon, 09 Jul 2018 16:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=G2uAeoq4DfhThX9UGnhckbXMfikniIsoGM7JqtwAgeE=; b=BlhWdrQdQObN6Qd3dd/qLgvGSfL8WL8Iu/kO0R0s1i1ORgRCkiSEnJ2b0H15tEicAu +uxrPb9/wSnO2Xu2sQOgyoBb5GVibE8T26/BlDC9hEnBzvkW7zJ5ir0+Q8JPyl3W2wnB 9+yM5BgN++j3Cdz6f0+3JtJcDyAdatG5/QgHg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=G2uAeoq4DfhThX9UGnhckbXMfikniIsoGM7JqtwAgeE=; b=MjxJLDrM3tHuBVkPI/yFOfLIbHcGR0m5cQuWLySU1yHuB67PIGinCDoddFjpll3Q6o p+r7dFf8/fGUAOhzncQ5pDTvSbfKk5UA+SHA8JP3hvjiLFz5gUZueamUJIoQDfoThvX5 JBS0ze0dOonOncPV4BqHYBFenxDVu9wRBu9WCNmZoCMY9WaLPmq+tJFG9f/WoTJh7eY6 VczuW/tpWBBb6eBgwRvvHL+597h0JIZoncDKEAj5mRYArgDGcNniSHRoMsrvr8OSO1Nr bdBYH0FHLNhIPRL7RJeEbfYCoFvH3Qgpp/mXjnJjjffCwzFeksoWAV5v1+6rFgv4kSAg RqNg== X-Gm-Message-State: APt69E0Wk3fnp9ehrMHJTn3Deu+v7pWdiBeiFYOJQIeTNO2r95zxmZek NNpnTqDRXmB+nC8cBZAoBIi+AQ== X-Received: by 2002:a17:902:70c6:: with SMTP id l6-v6mr22415286plt.286.1531179728447; Mon, 09 Jul 2018 16:42:08 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id h190-v6sm12823541pge.85.2018.07.09.16.42.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 16:42:07 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, ard.biesheuvel@linaro.org Cc: tbaicar@codeaurora.org, bhsharma@redhat.com, dyoung@redhat.com, james.morse@arm.com, mark.rutland@arm.com, al.stone@linaro.org, graeme.gregory@linaro.org, hanjun.guo@linaro.org, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org Subject: [PATCH v3.1 2/4] efi/arm: preserve early mapping of UEFI memory map longer for BGRT Date: Tue, 10 Jul 2018 08:42:27 +0900 Message-Id: <20180709234229.20181-3-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180709234229.20181-1-takahiro.akashi@linaro.org> References: <20180709234229.20181-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ard Biesheuvel The BGRT code validates the contents of the table against the UEFI memory map, and so it expects it to be mapped when the code runs. On ARM, this is currently not the case, since we tear down the early mapping after efi_init() completes, and only create the permanent mapping in arm_enable_runtime_services(), which executes as an early initcall, but still leaves a window where the UEFI memory map is not mapped. So move the call to efi_memmap_unmap() from efi_init() to arm_enable_runtime_services(). Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/arm-init.c | 1 - drivers/firmware/efi/arm-runtime.c | 2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) -- 2.17.0 Acked-by: James Morse diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c index b5214c143fee..388a929baf95 100644 --- a/drivers/firmware/efi/arm-init.c +++ b/drivers/firmware/efi/arm-init.c @@ -259,7 +259,6 @@ void __init efi_init(void) reserve_regions(); efi_esrt_init(); - efi_memmap_unmap(); memblock_reserve(params.mmap & PAGE_MASK, PAGE_ALIGN(params.mmap_size + diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c index 5889cbea60b8..59a8c0ec94d5 100644 --- a/drivers/firmware/efi/arm-runtime.c +++ b/drivers/firmware/efi/arm-runtime.c @@ -115,6 +115,8 @@ static int __init arm_enable_runtime_services(void) return 0; } + efi_memmap_unmap(); + if (efi_runtime_disabled()) { pr_info("EFI runtime services will be disabled.\n"); return 0; From patchwork Mon Jul 9 23:42:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 141496 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp3205230ljj; Mon, 9 Jul 2018 16:42:23 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdpfsiILyAm4vFPCorCtjsCOvwtcWZF3SJb4LZqzQEG67lOH8cDMUo1tRwyQw+3fNSc9U2O X-Received: by 2002:a62:1358:: with SMTP id b85-v6mr23393601pfj.238.1531179743287; Mon, 09 Jul 2018 16:42:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531179743; cv=none; d=google.com; s=arc-20160816; b=JF7UUJZyTEIs0kSFhJp45ikaLtMtmAgQb72cIcoaht2+xIIpuHryLb/i18eV6KqIyy LAjVzAVGBf7MHAlhJDRcrmNS4/aPCjUoVxSoel8sXfikoINgxvdHi8Jo+qtjmZL3I0Ud U+O09Hbf40NQUFHuNeP6LtlQBvvXRs1oOSICLYxR3VVD3GlCTOXMwvSKZ278Us8fkojm dFKUejQxPAqNGCDCYgFBuPrHuJEIj2DPVTvDYexOn5hTqJmszCYZHXvEwlvqFa0fePR6 C0cGLiypOJCf/vyBQ2OqfeWczpwM0GLSfVjlOx2vOD/LwHrsnK5oSUG/d2fL2oXTk1ws qRHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=6svwEjRZKw/fRIHWE4svwtkCI66G0b2U5AUFtaL5oWI=; b=SofT5UIoDWqUDOntWjp84kKfFmJkLCaqV/A4W09jexqt2RsEWgawSICHcOQ2JaCEr7 4JSQKInHPlkNlHVsy077jFBG5K/E5jankkirRjvOnmwSzCx7SyAdCst8dnKEqXrmdPjn 3+b0Pwba99JX1Mgy/rh1oUy4L32P57zjBu7afz4/cxiBXgYCobr4G17BFI0sXT3oaqen wLT6Bm3Cm7rHn8a+llnW1MDPBMlDiyVZfJH/tmRUVUXTswVk5sRUhZPm9E6JdcFrYQCN fpNIoN7Ly/77yz7z1ubvlle6ifYqEjBPufkMPe1q01XOwq958uR5U3K8BibukX1JtIaf bfPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=FeTciVgR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v4-v6si15510269pfm.151.2018.07.09.16.42.23; Mon, 09 Jul 2018 16:42:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=FeTciVgR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933412AbeGIXmU (ORCPT + 12 others); Mon, 9 Jul 2018 19:42:20 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:38244 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933313AbeGIXmR (ORCPT ); Mon, 9 Jul 2018 19:42:17 -0400 Received: by mail-pf0-f193.google.com with SMTP id x13-v6so4806297pfh.5 for ; Mon, 09 Jul 2018 16:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=6svwEjRZKw/fRIHWE4svwtkCI66G0b2U5AUFtaL5oWI=; b=FeTciVgRbk0YToviRxoz9bYqVWMSEQiEJeqNWbSeMvGwcrZJZo/UZyIrS27iadOssY JmTSWtU8+ugcFaFxk3q1QaRfTD+cKR/cEXRm8xLT0//nSgU91OvC496vj1eWzI429RGd aU37D3xacRIkpZEAoqbQ9u1z7MdC8h39cwdfU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=6svwEjRZKw/fRIHWE4svwtkCI66G0b2U5AUFtaL5oWI=; b=eDmjterxGIMaCoVI5crtZxDNbrC50y3vRCc7CU7eUSPFQBIkHMpOnpRSg/w3/iMSK+ iSJzD8cpVqdFVSUjbV5Pb85JsV/Pl9k/+vVwlnbunNbKFoY9WwZuN5I7a7XYcHoMRTIr SQyifI1YlVZrQ1Ifgwao+6pJXa6fZ+IA30H0+mvDT/HJZhDe+UOSmKhTht5g6Mhb8vSX bB20mAwyVDW15gOAheUH5c57eMXt+onL8YCfINR0Wnj7YkgCrovQgk4oYu5rXe9ouGlj yWF76FW9xjgnL9HPKcMGDDJNrG/4eHPOluQsIZn6TmaaIMJQCl5WpO4iPICluHoHw/54 YAtw== X-Gm-Message-State: APt69E3rnhy2fuobBg1yIWL++Tz4Wxl3tyM0lu6/Rme5uj5LGCKLGjSv /JWEyTkWkMz6tq4Z46W0IrvScw== X-Received: by 2002:a62:d34a:: with SMTP id q71-v6mr23092699pfg.17.1531179737032; Mon, 09 Jul 2018 16:42:17 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id b62-v6sm71862898pfm.97.2018.07.09.16.42.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 16:42:16 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, ard.biesheuvel@linaro.org Cc: tbaicar@codeaurora.org, bhsharma@redhat.com, dyoung@redhat.com, james.morse@arm.com, mark.rutland@arm.com, al.stone@linaro.org, graeme.gregory@linaro.org, hanjun.guo@linaro.org, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, AKASHI Takahiro Subject: [PATCH v3.1 3/4] efi/arm: map UEFI memory map even w/o runtime services enabled Date: Tue, 10 Jul 2018 08:42:28 +0900 Message-Id: <20180709234229.20181-4-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180709234229.20181-1-takahiro.akashi@linaro.org> References: <20180709234229.20181-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Under the current implementation, UEFI memory map will be mapped and made available in virtual mappings only if runtime services are enabled. But in a later patch, we want to use UEFI memory map in acpi_os_ioremap() to create mappings of ACPI tables using memory attributes described in UEFI memory map. See the following commit: arm64: acpi: fix alignment fault in accessing ACPI tables So, as a first step, arm_enter_runtime_services() is modified, alongside Ard's patch[1], so that UEFI memory map will not be freed even if efi=noruntime. [1] https://marc.info/?l=linux-efi&m=152930773507524&w=2 Signed-off-by: AKASHI Takahiro Reviewed-by: Ard Biesheuvel --- drivers/firmware/efi/arm-runtime.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) -- 2.17.0 diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c index 59a8c0ec94d5..a00934d263c5 100644 --- a/drivers/firmware/efi/arm-runtime.c +++ b/drivers/firmware/efi/arm-runtime.c @@ -117,6 +117,13 @@ static int __init arm_enable_runtime_services(void) efi_memmap_unmap(); + mapsize = efi.memmap.desc_size * efi.memmap.nr_map; + + if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) { + pr_err("Failed to remap EFI memory map\n"); + return 0; + } + if (efi_runtime_disabled()) { pr_info("EFI runtime services will be disabled.\n"); return 0; @@ -129,13 +136,6 @@ static int __init arm_enable_runtime_services(void) pr_info("Remapping and enabling EFI services.\n"); - mapsize = efi.memmap.desc_size * efi.memmap.nr_map; - - if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) { - pr_err("Failed to remap EFI memory map\n"); - return -ENOMEM; - } - if (!efi_virtmap_init()) { pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n"); return -ENOMEM; From patchwork Mon Jul 9 23:42:29 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 141497 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp3205362ljj; Mon, 9 Jul 2018 16:42:35 -0700 (PDT) X-Google-Smtp-Source: AAOMgpd6J7pawmh3ll9T6CLPxsIq2FAxU8dXCenBVWjU/+3f0Mn2Z6nMEK6GCXeZ2Bp/c0fGpIh9 X-Received: by 2002:a63:c20:: with SMTP id b32-v6mr14189501pgl.400.1531179754895; Mon, 09 Jul 2018 16:42:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531179754; cv=none; d=google.com; s=arc-20160816; b=UVG6EaUEAn9SYbiC7S7YCcRu4odgmXKMS6H4aPBCle3UU53jMlhT9rGthqkSrQfOs6 jfOprwq58KX5WkudCjl98V9cGAiTSBp+UKgDBnz/JCcaQ6V7e3Xa1hP2beogLnQIg7UM kzPqyxydyS52te9vipJpEis8EOAAFzOafoDRffRXwDBuBJPV37c+tDcSkTSQJGTohqgC iffmSYWOtjlZfNRcjhRrj1VLy40aKdZmD1/0bd4Xa6ue2775dSTefuYQzp8mpCgnM/E7 wg012ZxYzahpC+FNrntqI4LMgxh/MmvwczpmNHeBNJ7X2IGc6tQTZ8NXL1bBVnNfXRsm lLbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=8W7o3oy86/J1tw2fkmeq5q6MVz6b0M86D1KTHsBktO0=; b=tbQLfYnTsJq25Ximxo4Ttvw6vQ1V4/8+pzCy2y0satweijW52U0vkr+hbfeybWibMw pkhzDMf15Uy2G8YrPyLU6Y/0MfOMcimXBoZ7qVzeH6ksbF3qlWWoyLha3AWTEVkWNfWL JCD/U0fh2tMRzRf9HTkfPVyuf+rs5GqCh5oQB+PpXxoSBtujysJ5LWpuAn0RVScDz6fR DneaKxh5pTL3kn/nTg3GH8pCc7T6IuITVRl2Wc24oVAEP8ApxU4eRqsfm10xCgGITbxc 3KlW18sLKstSKpqJ1+g+O5W4H5CMBfZIyG2eJRqrxJPFvXJJy/TUKjtJRyxzE8JmEZIK aRfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=AhQiCjIE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d4-v6si15691647pfa.263.2018.07.09.16.42.34; Mon, 09 Jul 2018 16:42:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=AhQiCjIE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933433AbeGIXmb (ORCPT + 12 others); Mon, 9 Jul 2018 19:42:31 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:41289 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933209AbeGIXm3 (ORCPT ); Mon, 9 Jul 2018 19:42:29 -0400 Received: by mail-pf0-f196.google.com with SMTP id c21-v6so10120346pfn.8 for ; Mon, 09 Jul 2018 16:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=8W7o3oy86/J1tw2fkmeq5q6MVz6b0M86D1KTHsBktO0=; b=AhQiCjIECu9/zR+qGwxkxxMbPAeEhXfW6JcXM7c8tO8hv3hjxw5j6hqk3NI/0fh1pR Ipau4mN/X8TVlnlkGexox5l0yIzeGGuL76zi7YwYBASTo3D5ld3h1RvJziSHyT2bj96q 9FSjYqqw5B1RAYf39J0dwFJp/4LFBUUq7SJGE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=8W7o3oy86/J1tw2fkmeq5q6MVz6b0M86D1KTHsBktO0=; b=rwChBRLwBUWUjedhhJaUOpE+848WLsnYyXxtaJnpcF9PtzOSWsmgRCD7UdCCY7ScdK wimH0pRlxZNcT57D/wXuaU1wMi3UjTSKqwAfGxAKfXOtpsNQw+/wOJ3X6BjsRoDo/eik u+ble9AyCJYgMh6Irq4b9iwCwzTK+Zj4O9dW0PiaDb2vJRyvzoekGhRYWFE8WBlKkN2f R7gZRFIHuA9gyb7JEXwcJSErOm/c/ENsdBbBUyR2MRWQ4ihtx4N+3KZjFEWtzCYtZj82 tCnBGBTMkVtm+lyg0vH4coMHt1B/6sS9wZkegOSoAdpayJOmj/flOIzIVPZsa8mcQ+WV NmnA== X-Gm-Message-State: APt69E1a+9LsSho5P4ZWNlv3o7eo+tPlniLB2TygYT5BwZQAyobncVRe 7EW1P83Cu24efHbpd5FV3SvtBQ== X-Received: by 2002:a63:4450:: with SMTP id t16-v6mr20567863pgk.102.1531179748487; Mon, 09 Jul 2018 16:42:28 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id u71-v6sm6896003pfk.174.2018.07.09.16.42.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 16:42:27 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, ard.biesheuvel@linaro.org Cc: tbaicar@codeaurora.org, bhsharma@redhat.com, dyoung@redhat.com, james.morse@arm.com, mark.rutland@arm.com, al.stone@linaro.org, graeme.gregory@linaro.org, hanjun.guo@linaro.org, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, AKASHI Takahiro Subject: [PATCH v3.1 4/4] arm64: acpi: fix alignment fault in accessing ACPI Date: Tue, 10 Jul 2018 08:42:29 +0900 Message-Id: <20180709234229.20181-5-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180709234229.20181-1-takahiro.akashi@linaro.org> References: <20180709234229.20181-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a fix against the issue that crash dump kernel may hang up during booting, which can happen on any ACPI-based system with "ACPI Reclaim Memory." (kernel messages after panic kicked off kdump) (snip...) Bye! (snip...) ACPI: Core revision 20170728 pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707 Internal error: Oops: 96000021 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1 task: ffff000008d05180 task.stack: ffff000008cc0000 PC is at acpi_ns_lookup+0x25c/0x3c0 LR is at acpi_ds_load1_begin_op+0xa4/0x294 (snip...) Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000) Call trace: (snip...) [] acpi_ns_lookup+0x25c/0x3c0 [] acpi_ds_load1_begin_op+0xa4/0x294 [] acpi_ps_build_named_op+0xc4/0x198 [] acpi_ps_create_op+0x14c/0x270 [] acpi_ps_parse_loop+0x188/0x5c8 [] acpi_ps_parse_aml+0xb0/0x2b8 [] acpi_ns_one_complete_parse+0x144/0x184 [] acpi_ns_parse_table+0x48/0x68 [] acpi_ns_load_table+0x4c/0xdc [] acpi_tb_load_namespace+0xe4/0x264 [] acpi_load_tables+0x48/0xc0 [] acpi_early_init+0x9c/0xd0 [] start_kernel+0x3b4/0x43c Code: b9008fb9 2a000318 36380054 32190318 (b94002c0) ---[ end trace c46ed37f9651c58e ]--- Kernel panic - not syncing: Fatal exception Rebooting in 10 seconds.. (diagnosis) * This fault is a data abort, alignment fault (ESR=0x96000021) during reading out ACPI table. * Initial ACPI tables are normally stored in system ram and marked as "ACPI Reclaim memory" by the firmware. * After the commit f56ab9a5b73c ("efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP"), those regions are differently handled as they are "memblock-reserved", without NOMAP bit. * So they are now excluded from device tree's "usable-memory-range" which kexec-tools determines based on a current view of /proc/iomem. * When crash dump kernel boots up, it tries to accesses ACPI tables by mapping them with ioremap(), not ioremap_cache(), in acpi_os_ioremap() since they are no longer part of mapped system ram. * Given that ACPI accessor/helper functions are compiled in without unaligned access support (ACPI_MISALIGNMENT_NOT_SUPPORTED), any unaligned access to ACPI tables can cause a fatal panic. With this patch, acpi_os_ioremap() always honors memory attribute information provided by the firmware (EFI) and retaining cacheability allows the kernel safe access to ACPI tables. Signed-off-by: AKASHI Takahiro Reviewed-by: James Morse Reviewed-by: Ard Biesheuvel Reported-by and Tested-by: Bhupesh Sharma --- arch/arm64/include/asm/acpi.h | 23 ++++++++++++++++------- arch/arm64/kernel/acpi.c | 11 +++-------- 2 files changed, 19 insertions(+), 15 deletions(-) -- 2.17.0 diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index 0db62a4cbce2..68bc18cb2b85 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -12,10 +12,12 @@ #ifndef _ASM_ACPI_H #define _ASM_ACPI_H +#include #include #include #include +#include #include #include @@ -29,18 +31,22 @@ /* Basic configuration for ACPI */ #ifdef CONFIG_ACPI +pgprot_t __acpi_get_mem_attribute(phys_addr_t addr); + /* ACPI table mapping after acpi_permanent_mmap is set */ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) { + /* For normal memory we already have a cacheable mapping. */ + if (memblock_is_map_memory(phys)) + return (void __iomem *)__phys_to_virt(phys); + /* - * EFI's reserve_regions() call adds memory with the WB attribute - * to memblock via early_init_dt_add_memory_arch(). + * We should still honor the memory's attribute here because + * crash dump kernel possibly excludes some ACPI (reclaim) + * regions from memblock list. */ - if (!memblock_is_memory(phys)) - return ioremap(phys, size); - - return ioremap_cache(phys, size); + return __ioremap(phys, size, __acpi_get_mem_attribute(phys)); } #define acpi_os_ioremap acpi_os_ioremap @@ -129,7 +135,10 @@ static inline const char *acpi_get_enable_method(int cpu) * for compatibility. */ #define acpi_disable_cmcff 1 -pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr); +static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr) +{ + return __acpi_get_mem_attribute(addr); +} #endif /* CONFIG_ACPI_APEI */ #ifdef CONFIG_ACPI_NUMA diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index 7b09487ff8fb..ed46dc188b22 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -29,13 +30,9 @@ #include #include +#include #include -#ifdef CONFIG_ACPI_APEI -# include -# include -#endif - int acpi_noirq = 1; /* skip ACPI IRQ initialization */ int acpi_disabled = 1; EXPORT_SYMBOL(acpi_disabled); @@ -239,8 +236,7 @@ void __init acpi_boot_table_init(void) } } -#ifdef CONFIG_ACPI_APEI -pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr) +pgprot_t __acpi_get_mem_attribute(phys_addr_t addr) { /* * According to "Table 8 Map: EFI memory types to AArch64 memory @@ -261,4 +257,3 @@ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr) return __pgprot(PROT_NORMAL_NC); return __pgprot(PROT_DEVICE_nGnRnE); } -#endif