Received: by 10.223.185.116 with SMTP id b49csp8311473wrg; Thu, 1 Mar 2018 22:40:02 -0800 (PST) X-Google-Smtp-Source: AG47ELv/3FIy6Z16Z6U4yNNgslEIgz1dLBOlLszT72XVLwx2AlMLq+MFBq2VvibGiWKufbZ7FkW/ X-Received: by 2002:a17:902:a610:: with SMTP id u16-v6mr4171208plq.293.1519972802667; Thu, 01 Mar 2018 22:40:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519972802; cv=none; d=google.com; s=arc-20160816; b=v6YWvkRKZ8X7UjkWpNn70tSMMSZyvog3nHolU6NtLtXttbSgKsHRy4Q7ovQVWG77qs Q52vCsRSff/eQ5aWSSrjYM+6VIENUcjYyLuDkbFa68jPlGvu92RLTV2J0Q5b7qP3DRKh 9vbGHRSmyicGRXRVrtL61Df7Ac/+BObRE4r5ey9xkoh3QNblG8arCVuqFm0mpj6Q8uMz y8RN5GJfYtfsJbRuxL45BNRtOvFSusrANOOr3NFRpTp6ptG+1q7phtAoe8IksDq9XSwT aBMU2UthNm1wsL9h06D5BaUXL7REYa662SVQhSuE6Zax0tqqVVfQwkhEZwGgZCJb4yN8 BeYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=JqcrT9tuep7zQEqEpzXyf7fnIQdUS3/QOCKkauGpH54=; b=BclyYVDtLWnNf9W0bSBdLEWM/hSGBSDRpFp8hEXAgUr9qUKvDQEd4QBcCcY3KaVPpM UG4+jF0kO6eJxr2oyDJi200eYt6oHutbPnqzI37L/YAiLKRq2jx+i17Vsl+QT+cyaxfJ TK4I/Y4377paBZkf6LUTFvnFlZNRs+UhSDVKKKHHOqxTOBrk+GoJPppslDokLona0zrK nXTBRcTAKVxbtV03/y9kgQFGL18fAYn8IoDMJZjBXhPNgyS5XYhCHFReuGU/vrYFIukr gSXzhOZ7jBO2jIcVKI0EMbuPoMRXp4NI+jgqxC37lSR+0eRl8Btm1zkQvybZGL3e9R8o zsag== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z3si3614759pgs.71.2018.03.01.22.39.46; Thu, 01 Mar 2018 22:40:02 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935971AbeCBGLY (ORCPT + 99 others); Fri, 2 Mar 2018 01:11:24 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:33770 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932310AbeCBGLX (ORCPT ); Fri, 2 Mar 2018 01:11:23 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C27B640FB658; Fri, 2 Mar 2018 06:11:22 +0000 (UTC) Received: from dhcp-128-65.nay.redhat.com (ovpn-12-90.pek2.redhat.com [10.72.12.90]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6703010AF9C5; Fri, 2 Mar 2018 06:11:18 +0000 (UTC) Date: Fri, 2 Mar 2018 14:11:14 +0800 From: Dave Young To: AKASHI Takahiro Cc: vgoyal@redhat.com, bhe@redhat.com, mpe@ellerman.id.au, bauerman@linux.vnet.ibm.com, prudo@linux.vnet.ibm.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org Subject: Re: [PATCH 1/7] kexec_file: make an use of purgatory optional Message-ID: <20180302061114.GE15422@dhcp-128-65.nay.redhat.com> References: <20180227044814.24808-1-takahiro.akashi@linaro.org> <20180227044814.24808-2-takahiro.akashi@linaro.org> <20180302055859.GB15422@dhcp-128-65.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180302055859.GB15422@dhcp-128-65.nay.redhat.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Fri, 02 Mar 2018 06:11:22 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Fri, 02 Mar 2018 06:11:22 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'dyoung@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/02/18 at 01:58pm, Dave Young wrote: > On 02/27/18 at 01:48pm, AKASHI Takahiro wrote: > > On arm64, crash dump kernel's usable memory is protected by > > *unmapping* it from kernel virtual space unlike other architectures > > where the region is just made read-only. It is highly unlikely that > > the region is accidentally corrupted and this observation rationalizes > > that digest check code can also be dropped from purgatory. > > The resulting code is so simple as it doesn't require a bit ugly > > re-linking/relocation stuff, i.e. arch_kexec_apply_relocations_add(). > > > > Please see: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/545428.html > > All that the purgatory does is to shuffle arguments and jump into a new > > kernel, while we still need to have some space for a hash value > > (purgatory_sha256_digest) which is never checked against. > > > > As such, it doesn't make sense to have trampline code between old kernel > > and new kernel on arm64. > > > > This patch introduces a new configuration, ARCH_HAS_KEXEC_PURGATORY, and > > allows related code to be compiled in only if necessary. > > > > Signed-off-by: AKASHI Takahiro > > Cc: Dave Young > > Cc: Vivek Goyal > > Cc: Baoquan He > > --- > > arch/powerpc/Kconfig | 3 +++ > > arch/x86/Kconfig | 3 +++ > > kernel/kexec_file.c | 6 ++++++ > > 3 files changed, 12 insertions(+) > > > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > > index 73ce5dd07642..c32a181a7cbb 100644 > > --- a/arch/powerpc/Kconfig > > +++ b/arch/powerpc/Kconfig > > @@ -552,6 +552,9 @@ config KEXEC_FILE > > for kernel and initramfs as opposed to a list of segments as is the > > case for the older kexec call. > > > > +config ARCH_HAS_KEXEC_PURGATORY > > + def_bool KEXEC_FILE > > + > > config RELOCATABLE > > bool "Build a relocatable kernel" > > depends on PPC64 || (FLATMEM && (44x || FSL_BOOKE)) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index c1236b187824..f031c3efe47e 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -2019,6 +2019,9 @@ config KEXEC_FILE > > for kernel and initramfs as opposed to list of segments as > > accepted by previous system call. > > > > +config ARCH_HAS_KEXEC_PURGATORY > > + def_bool KEXEC_FILE > > + > > config KEXEC_VERIFY_SIG > > bool "Verify kernel signature during kexec_file_load() syscall" > > depends on KEXEC_FILE > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c > > index e5bcd94c1efb..990adae52151 100644 > > --- a/kernel/kexec_file.c > > +++ b/kernel/kexec_file.c > > @@ -26,7 +26,11 @@ > > #include > > #include "kexec_internal.h" > > > > +#ifdef CONFIG_ARCH_HAS_KEXEC_PURGATORY > > static int kexec_calculate_store_digests(struct kimage *image); > > +#else > > +static int kexec_calculate_store_digests(struct kimage *image) { return 0; }; > > +#endif > > > > /* Architectures can provide this probe function */ > > int __weak arch_kexec_kernel_image_probe(struct kimage *image, void *buf, > > @@ -520,6 +524,7 @@ int kexec_add_buffer(struct kexec_buf *kbuf) > > return 0; > > } > > > > +#ifdef CONFIG_ARCH_HAS_KEXEC_PURGATORY > > /* Calculate and store the digest of segments */ > > static int kexec_calculate_store_digests(struct kimage *image) > > { > > @@ -1022,3 +1027,4 @@ int kexec_purgatory_get_set_symbol(struct kimage *image, const char *name, > > > > return 0; > > } > > +#endif /* CONFIG_ARCH_HAS_KEXEC_PURGATORY */ > > -- > > 2.16.2 > > > > For this one, I think purgatory digest verification is still good to > have, but I do not insist since this is arch specific. > > If nobody else objects then I think I can ack the series after some > testing passed. For the #ifdefs, they can be changed to IS_ENABLED like other similar thing. > > Thanks > Dave