From patchwork Fri Jun 15 07:56:21 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 138658 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp519325lji; Fri, 15 Jun 2018 00:56:25 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJsMag8mQJ+xeNlgjPcIjSqoFyImAd9uXMCev/8JjypJwgkb3XbBslTpBoLT4O9/rYrdivF X-Received: by 2002:a17:902:8604:: with SMTP id f4-v6mr788807plo.4.1529049385384; Fri, 15 Jun 2018 00:56:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529049385; cv=none; d=google.com; s=arc-20160816; b=zwkcbtJGwSed9numXsRgRcTkEWeS8gvqmg+WuFERBQn72T97ppFtCnHSjbGNw5MhVN YUY1g3bAmbFCwgVgXns04yVrquHIOkg4BNSCrVs+evU28+Uz1Rz0nr+0dn6mR6vfqt4g go2jO+SKcyZr1th8u44UW3s8CUsXjDnLN1fHnEfuBPB4QgiuDmHvqPvVm96yJQ22HZvB qy5BakLgc2p3l4rUoUNXW2KhK4Hy/9MXZdjPvltpGHlUiBpq3b6GrWbs7BEKeslzDtrz 4kXktmuUkTCjeJ1ik/SlG+FLTFTZuDBRKmXCF0MeigHhVBYyDpN/TAshn7jDZH8NJo42 PRCw== 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=fMJ059I9Pwpj92i+n/S50FPN4apoi+2vr23cvPMQsMY=; b=bd540x3Tt7KdGyKNv1YF+AuDxZTXi4rMwvZVFOpkvlU4VgEWjdYaoK9OhSkidcJBaj z046XiWh4B1HbcFyw27N79UUKu9m1Tz7OCMKkap0frDRpNK+c0ZeyFv+CrPBaihp7mo0 g/8Otajx+juEQBEVwqlPqjBgjN/yT2fnW1+AJB8H3hdKugT5fTi+/soI2ywOIt0d6dAL W6a0EFT52ecA877dbxvi3p+gHl6i3y45V8NChEG+btAc0m5idf5mpZNnkrhJNZtvF3E8 QSe32Nbxqa/j1Q8xScSjeAFMZES4B/+8btVNVglFNz7uk+QbL142n7MCMYUrlheqjubC zDDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MSoyGnle; 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 e95-v6si7483209plb.239.2018.06.15.00.56.25; Fri, 15 Jun 2018 00:56:25 -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=MSoyGnle; 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 S1755972AbeFOH4X (ORCPT + 30 others); Fri, 15 Jun 2018 03:56:23 -0400 Received: from mail-pg0-f66.google.com ([74.125.83.66]:44976 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755925AbeFOH4U (ORCPT ); Fri, 15 Jun 2018 03:56:20 -0400 Received: by mail-pg0-f66.google.com with SMTP id p21-v6so4078555pgd.11 for ; Fri, 15 Jun 2018 00:56:20 -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=fMJ059I9Pwpj92i+n/S50FPN4apoi+2vr23cvPMQsMY=; b=MSoyGnley1Z1Ck24b5BR2GqAtgAKtiz7OIEKeAAmi9N/0VBXz9l4bS4m9GfK+qr++3 yqK7YlT+Uz+QCQTlZ2k4Sk7/GTm1XwOI7I/IKjh4qKfLrUQIlH22MUmertZG2NGQVAoz +z2cI7j2iEc4gp6W9/NVatyF3Q01o95C9KibQ= 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=fMJ059I9Pwpj92i+n/S50FPN4apoi+2vr23cvPMQsMY=; b=IHjr7WjIFQzXhHBnirVMM4kRoE9/cb4NiRHHbSp9yrX3bX7fXcPY6Pj1SgZWb6vmWJ 2vnYzn9l3iRGex+6VOo+FlaGxGhPHW2cb/HNnVo75n7x1LZimoX/kNmuwr/1B+lQf2hz 59TBeh4jgnWWe34nHN63f5x2Wo8+UB4urVOTMNIzS5DnXzb4M3u//GOb8ADPZyZVfLIV I1cvw7lMDh0x6WNUqRWf5xCKIgRuWGQZNpmMQK8xobjnRABM8/8L6fGzCckjXKIM/us6 CFC3PFieQav1DeH/El0+dRA8ooshgOZ4vmL6KY78JnzjOPSIM1Ng9imy73CvDV8KZsh9 GCUQ== X-Gm-Message-State: APt69E0+eOW4OFakYsYhfSntE4NksIutgg8RC7OEz2O+j/T8vma4bqH0 dpEo1HbzyTE78Zh3rV78Lfbdyw== X-Received: by 2002:a63:7f44:: with SMTP id p4-v6mr595097pgn.416.1529049380265; Fri, 15 Jun 2018 00:56:20 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id d9-v6sm11862437pfg.183.2018.06.15.00.56.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 00:56:19 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, akpm@linux-foundation.org, 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 1/3] arm64: export memblock_reserve()d regions via /proc/iomem Date: Fri, 15 Jun 2018 16:56:21 +0900 Message-Id: <20180615075623.13454-2-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180615075623.13454-1-takahiro.akashi@linaro.org> References: <20180615075623.13454-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") CC: 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)