From mboxrd@z Thu Jan 1 00:00:00 1970 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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 A3765C55185 for ; Wed, 22 Apr 2020 12:14:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5DBD92084D for ; Wed, 22 Apr 2020 12:14:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5DBD92084D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EE2F18E0013; Wed, 22 Apr 2020 08:14:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E6B748E0003; Wed, 22 Apr 2020 08:14:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D33738E0013; Wed, 22 Apr 2020 08:14:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0041.hostedemail.com [216.40.44.41]) by kanga.kvack.org (Postfix) with ESMTP id B75A98E0003 for ; Wed, 22 Apr 2020 08:14:17 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 79B9652B0 for ; Wed, 22 Apr 2020 12:14:17 +0000 (UTC) X-FDA: 76735383354.22.wound14_5f9ec14770a30 X-HE-Tag: wound14_5f9ec14770a30 X-Filterd-Recvd-Size: 4637 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Apr 2020 12:14:16 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 12D4931B; Wed, 22 Apr 2020 05:14:16 -0700 (PDT) Received: from [192.168.0.14] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D04733F6CF; Wed, 22 Apr 2020 05:14:14 -0700 (PDT) Subject: Re: [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use To: "Eric W. Biederman" Cc: kexec@lists.infradead.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , Andrew Morton , Will Deacon References: <20200326180730.4754-1-james.morse@arm.com> <87sgh4h4r7.fsf@x220.int.ebiederm.org> From: James Morse Message-ID: <59b74cc5-89aa-83fa-5532-8e64d6382fdd@arm.com> Date: Wed, 22 Apr 2020 13:14:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <87sgh4h4r7.fsf@x220.int.ebiederm.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Eric, On 15/04/2020 21:29, Eric W. Biederman wrote: > James Morse writes: > >> Hello! >> >> arm64 recently queued support for memory hotremove, which led to some >> new corner cases for kexec. >> >> If the kexec segments are loaded for a removable region, that region may >> be removed before kexec actually occurs. This causes the first kernel to >> lockup when applying the relocations. (I've triggered this on x86 too). >> >> The first patch adds a memory notifier for kexec so that it can refuse >> to allow in-use regions to be taken offline. >> >> >> This doesn't solve the problem for arm64, where the new kernel must >> initially rely on the data structures from the first boot to describe >> memory. These don't describe hotpluggable memory. >> If kexec places the kernel in one of these regions, it must also provide >> a DT that describes the region in which the kernel was mapped as memory. >> (and somehow ensure its always present in the future...) >> >> To prevent this from happening accidentally with unaware user-space, >> patches two and three allow arm64 to give these regions a different >> name. >> >> This is a change in behaviour for arm64 as memory hotadd and hotremove >> were added separately. >> >> >> I haven't tried kdump. >> Unaware kdump from user-space probably won't describe the hotplug >> regions if the name is different, which saves us from problems if >> the memory is no longer present at kdump time, but means the vmcore >> is incomplete. >> >> >> These patches are based on arm64's for-next/core branch, but can all >> be merged independently. > > So I just looked through these quickly and I think there are real > problems here we can fix, and that are worth fixing. > > However I am not thrilled with the fixes you propose. Sure. Unfortunately /proc/iomem is the only trick arm64 has to keep the existing kexec-tools working. (We've had 'unthrilling' patches like this before to prevent user-space from loading the kernel over the top of the in-memory firmware tables.) arm64 expects the description of memory to come from firmware, be that UEFI for memory present at boot, or the ACPI AML methods for memory that was added later. On arm64 there is no standard location for memory. The kernel has to be handed a pointer to the firmware tables that describe it. The kernel expects to boot from memory that was present at boot. Modifying the firmware tables at runtime doesn't solve the problem as we may need to move the firmware-reserved memory region that describes memory. User-space may still load and kexec either side of that update. Even if we could modify the structures at runtime, we can't update a loaded kexec image. We have no idea which blob from userspace is the DT. It may not even be linux that has been loaded. We can't emulate parts of UEFI's handover because kexec's purgatory isn't an EFI program. I can't see a path through all this. If we have to modify existing user-space, I'd rather leave it broken. We can detect the problem in the arch code and print a warning at load time. James