Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp225924pxb; Mon, 13 Sep 2021 17:40:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxn7r9WfnvghbbVtTJ3A1KiRopZY3qsF4RB1/GxMTph8oDJubE/iuoftUiZabUx2IeeGVk7 X-Received: by 2002:a17:906:dfe3:: with SMTP id lc3mr4320278ejc.478.1631580022449; Mon, 13 Sep 2021 17:40:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631580022; cv=none; d=google.com; s=arc-20160816; b=rxNvdOo80sYTlhSd0imk5L3ZX04c69N2hm72yrDCpLGJJGHsQY5+Kpc7Dytgrvb2ZG mn//t5qQjEukH8+YpJ4PBPo3rn4dXlahwDJ/YjnAY2V/7i8EMBj4IaP278M1VXm7g83g PQ3dvv9lotrfMyomet5BFHi4Z7VNmKPOBYbGF1+gR6ks8hUtvIsDg7bDC68/lMPdxa2B qTg9NWx4WeIL76WddhYLTTz/80y7Mqrs9V813Xi86XfpFtBaYTwesHhv7hmxExNy/hvf yjt7o2G014P697jIce68BrvXAovU4wKCkJrTb32DYC6Nisq3SlIxTvHdvbBghxqjN1lV Ev/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=bzzdrH9Hz+9TbY3xhhR4RGy0m89TbdCMjo/Gt8UJnBI=; b=0mgXCGZ4HcosCJM0PEBoYaxq769e7zMYTTTGC7z3GnLX+bKIxjMPVg32ou9F0ru08x G9+rSZbes5EJqI+PVxod4lT+E8KvbOZ4rn4MCur+im6QiNkGLzlPeO+z4KXhcEkSMJjJ jfMK2t7SA4kI7sTmEQb6caBVfLKKLAj3Kh3sPqN6AgpcBwT/nALUtoiderGkFNUCV4Ok m2332wpaEAUDKY9syaYLWebeFi08Evl1hAnDJepRr2m9RAD3RoFAtfXZYTKRKL2M/Nhi fJNmIhxLeISFlrgdhxyKq+lzHWAk+C92h0rdHSkJH3FWAtijfFqsgW3pQSbJF4SZ+uIs 8n2w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gx11si3627328ejc.521.2021.09.13.17.39.58; Mon, 13 Sep 2021 17:40:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245692AbhIMP5k (ORCPT + 99 others); Mon, 13 Sep 2021 11:57:40 -0400 Received: from 8bytes.org ([81.169.241.247]:56796 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231407AbhIMP5f (ORCPT ); Mon, 13 Sep 2021 11:57:35 -0400 Received: from cap.home.8bytes.org (p549ad441.dip0.t-ipconnect.de [84.154.212.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by theia.8bytes.org (Postfix) with ESMTPSA id B6F512A6; Mon, 13 Sep 2021 17:56:16 +0200 (CEST) From: Joerg Roedel To: x86@kernel.org Cc: Eric Biederman , kexec@lists.infradead.org, Joerg Roedel , stable@vger.kernel.org, hpa@zytor.com, Andy Lutomirski , Dave Hansen , Peter Zijlstra , Jiri Slaby , Dan Williams , Tom Lendacky , Juergen Gross , Kees Cook , David Rientjes , Cfir Cohen , Erdem Aktas , Masami Hiramatsu , Mike Stunes , Sean Christopherson , Martin Radev , Arvind Sankar , Joerg Roedel , linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: [PATCH v2 01/12] kexec: Allow architecture code to opt-out at runtime Date: Mon, 13 Sep 2021 17:55:52 +0200 Message-Id: <20210913155603.28383-2-joro@8bytes.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210913155603.28383-1-joro@8bytes.org> References: <20210913155603.28383-1-joro@8bytes.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Joerg Roedel Allow a runtime opt-out of kexec support for architecture code in case the kernel is running in an environment where kexec is not properly supported yet. This will be used on x86 when the kernel is running as an SEV-ES guest. SEV-ES guests need special handling for kexec to hand over all CPUs to the new kernel. This requires special hypervisor support and handling code in the guest which is not yet implemented. Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Joerg Roedel --- include/linux/kexec.h | 1 + kernel/kexec.c | 14 ++++++++++++++ kernel/kexec_file.c | 9 +++++++++ 3 files changed, 24 insertions(+) diff --git a/include/linux/kexec.h b/include/linux/kexec.h index 0c994ae37729..85c30dcd0bdc 100644 --- a/include/linux/kexec.h +++ b/include/linux/kexec.h @@ -201,6 +201,7 @@ int arch_kexec_kernel_verify_sig(struct kimage *image, void *buf, unsigned long buf_len); #endif int arch_kexec_locate_mem_hole(struct kexec_buf *kbuf); +bool arch_kexec_supported(void); extern int kexec_add_buffer(struct kexec_buf *kbuf); int kexec_locate_mem_hole(struct kexec_buf *kbuf); diff --git a/kernel/kexec.c b/kernel/kexec.c index b5e40f069768..275cda429380 100644 --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -190,11 +190,25 @@ static int do_kexec_load(unsigned long entry, unsigned long nr_segments, * that to happen you need to do that yourself. */ +bool __weak arch_kexec_supported(void) +{ + return true; +} + static inline int kexec_load_check(unsigned long nr_segments, unsigned long flags) { int result; + /* + * The architecture may support kexec in general, but the kernel could + * run in an environment where it is not (yet) possible to execute a new + * kernel. Allow the architecture code to opt-out of kexec support when + * it is running in such an environment. + */ + if (!arch_kexec_supported()) + return -ENOSYS; + /* We only trust the superuser with rebooting the system. */ if (!capable(CAP_SYS_BOOT) || kexec_load_disabled) return -EPERM; diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index 33400ff051a8..96d08a512e9c 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -358,6 +358,15 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd, int ret = 0, i; struct kimage **dest_image, *image; + /* + * The architecture may support kexec in general, but the kernel could + * run in an environment where it is not (yet) possible to execute a new + * kernel. Allow the architecture code to opt-out of kexec support when + * it is running in such an environment. + */ + if (!arch_kexec_supported()) + return -ENOSYS; + /* We only trust the superuser with rebooting the system. */ if (!capable(CAP_SYS_BOOT) || kexec_load_disabled) return -EPERM; -- 2.33.0