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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 CA3E4C2BA19 for ; Tue, 14 Apr 2020 09:16:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7502F206E9 for ; Tue, 14 Apr 2020 09:16:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZrEOPrcS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7502F206E9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 24F178E0005; Tue, 14 Apr 2020 05:16:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 200EE8E0001; Tue, 14 Apr 2020 05:16:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 116738E0005; Tue, 14 Apr 2020 05:16:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0021.hostedemail.com [216.40.44.21]) by kanga.kvack.org (Postfix) with ESMTP id EAEEA8E0001 for ; Tue, 14 Apr 2020 05:16:44 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 97C5B8245578 for ; Tue, 14 Apr 2020 09:16:44 +0000 (UTC) X-FDA: 76705905528.03.nest36_7506f5c0a2141 X-HE-Tag: nest36_7506f5c0a2141 X-Filterd-Recvd-Size: 9119 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Apr 2020 09:16:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586855803; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=m87sG7ldnCtMtGF7GpBTNkXwGQ0DdlqvytJhzpKn2To=; b=ZrEOPrcSIt5H+s5OpnRI+G7baONiwX7AR2GlM6qrGIMMBvlFaytZXTDCei2PnAGYqv0ZTD 1niWFPmedGso8Wo5epUpbsKylEFgOGkBxi2BezDQLlvz57RFWA35nIYubiNhvDI7jUbHq3 zjj22WkM5doYxLgzvgA4le0yOMdmS2o= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-471-jHtuHLK2MGW3grQcmLcBeQ-1; Tue, 14 Apr 2020 05:16:39 -0400 X-MC-Unique: jHtuHLK2MGW3grQcmLcBeQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 64BC918B9FDA; Tue, 14 Apr 2020 09:16:32 +0000 (UTC) Received: from dhcp-128-65.nay.redhat.com (ovpn-12-221.pek2.redhat.com [10.72.12.221]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 79956A1880; Tue, 14 Apr 2020 09:16:22 +0000 (UTC) Date: Tue, 14 Apr 2020 17:16:17 +0800 From: Dave Young To: "Eric W. Biederman" Cc: Baoquan He , David Hildenbrand , Catalin Marinas , Bhupesh Sharma , Anshuman Khandual , kexec@lists.infradead.org, Russell King - ARM Linux admin , linux-mm@kvack.org, James Morse , Andrew Morton , Will Deacon , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image Message-ID: <20200414091617.GA43656@dhcp-128-65.nay.redhat.com> References: <20200410121013.03b609fd572504c03a666f4a@linux-foundation.org> <20200411034414.GH2129@MiWiFi-R3L-srv> <20200411093009.GH25745@shell.armlinux.org.uk> <20200412053507.GA4247@MiWiFi-R3L-srv> <20200412080836.GM25745@shell.armlinux.org.uk> <87wo6klbw0.fsf@x220.int.ebiederm.org> <20200413023701.GA20265@MiWiFi-R3L-srv> <871rorjzmc.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 In-Reply-To: <871rorjzmc.fsf@x220.int.ebiederm.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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: On 04/13/20 at 08:15am, Eric W. Biederman wrote: > Baoquan He writes: >=20 > > On 04/12/20 at 02:52pm, Eric W. Biederman wrote: > >>=20 > >> The only benefit of kexec_file_load is that it is simple enough from a > >> kernel perspective that signatures can be checked. > > > > We don't have this restriction any more with below commit: > > > > commit 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG > > and KEXEC_SIG_FORCE") > > > > With KEXEC_SIG_FORCE not set, we can use kexec_load_file to cover both > > secure boot or legacy system for kexec/kdump. Being simple enough is > > enough to astract and convince us to use it instead. And kexec_file_loa= d > > has been in use for several years on systems with secure boot, since > > added in 2014, on x86_64. >=20 > No. Actaully kexec_file_load is the less capable interface, and less > flexible interface. Which is why it is appropriate for signature > verification. I agreed that the user space design is more flexible, but as for the common use case of loading bzImage (say x86 as an example) the kexec_file_load is good enough. We could have other potential improvement= based on kexec_file_load. For example we could use it to do some early kdump loading, eg. try to load an attached kdump kernel immediately once the crashkernel memory get reserved. >=20 > >> kexec_load in every other respect is the more capable and functional > >> interface. It makes no sense to get rid of it. We do not remove kexec_load at all, it is indeed helpful in many cases as all agreed. But if we have a bug reported for both we may fix kexec_file_load first because it is usually easier, also do not need to worry about too much about old kernel and new kernel compatibility. For example the recent breakage we found in efi path, kexec_file_load just work after the efi cleanup, but kexec_load depends on the ABI we added, so we must fix it as below: https://lore.kernel.org/linux-efi/20200410135644.GB6772@dhcp-128-65.nay.red= hat.com/=20 > >>=20 > >> It does make sense to reload with a loaded kernel on memory hotplug. > >> That is simple and easy. If we are going to handle something in the > >> kernel it should simple an automated unloading of the kernel on memory > >> hotplug. > >>=20 > >>=20 > >> I think it would be irresponsible to deprecate kexec_load on any > >> platform. > >>=20 > >> I also suspect that kexec_file_load could be taught to copy the dtb > >> on arm32 if someone wants to deal with signatures. > >>=20 > >> We definitely can not even think of deprecating kexec_load until > >> architecture that supports it also supports kexec_file_load and everyo= ne > >> is happy with that interface. That is Linus's no regression rule. > > > > I should pick a milder word to express our tendency and tell our plan > > then 'obsolete'. Even though I added 'gradually', seems it doesn't help > > much. I didn't mean to say 'deprecate' at all when replied. > > > > The situation and trend I understand about kexec_load and kexec_file_lo= ad > > are: > > > > 1) Supporting kexec_file_load is suggested to add in ARCHes which don't > > have yet, just as x86_64, arm64 and s390 have done; > > =20 > > 2) kexec_file_load is suggested to use, and take precedence over > > kexec_load in the future, if both are supported in one ARCH. >=20 > The deep problem is that kexec_file_load is distinctly less expressive > than kexec_load. >=20 > > 3) Kexec_load is kept being used by ARCHes w/o kexc_file_load support, > > and by ARCHes for back compatibility w/ kexec_file_load support. > > > > For 1) and 2), I think the reason is obvious as Eric said, > > kexec_file_load is simple enough. And currently, whenever we got a bug > > report, we may need fix them twice, for kexec_load and kexec_file_load. > > If kexec_file_load is made by default, e.g on x86_64, we will change it > > in kernel space only, for kexec_file_load. This is what I meant about > > 'obsolete gradually'. I think for arm64, s390, they will do these too. > > Unless there's some critical/blocker bug in kexec_load, to corrupt the > > old kexec_load interface in old product. >=20 > Maybe. The code that kexec_file_load sucked into the kernel is quite > stable and rarely needs changes except during a port of kexec to > another architecture. >=20 > Last I looked the real maintenance effor of kexec and kexec on panic was > in the drivers. So I don't think we can use maintenance to do anything. >=20 > > For 3), people can still use kexec_load and develop/fix for it, if no > > kexec_file_load supported. But 32-bit arm should be a different one, > > more like i386, we will leave it as is, and fix anything which could > > break it. But people really expects to improve or add feature to it? E.= g > > in this patchset, the mem hotplug issue James raised, I assume James is > > focusing on arm64, x86_64, but not 32-bit arm. As DavidH commented in > > another reply, people even don't agree to continue supporting memory > > hotplug on 32-bit system. We ever took effort to fix a memory hotplug > > bug on i386 with a patch, but people would rather set it as BROKEN. >=20 > For memory hotplug just reload. Userspace already gets good events. >=20 > We should not expect anything except a panic kernel to be loaded over a > memory hotplug event. The kexec on panic code should actually be loaded > in a location that we don't reliquish if asked for it. >=20 > Quite frankly at this point I would love to see the signature fad die, > which would allow us to remove kexec_file_load. I still have not seen > the signature code used anywhere except by people anticipating trouble. Same to me, I also hate the Secure Boot, and I also do not like the trouble added by signature verification. But still we found that beyond of Secure Boot use cases it is also useful in other usual cases. And since kernel has the lockdown supported we have to leave with it. Thanks Dave