Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp1197747pxy; Thu, 6 May 2021 02:41:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwUa2KwhaLGSbNwjR4nfaDlQl+zYKKt2aHjtbkt/BMhVVK1meFBWZ/8nBCXxLLgpAbRuRu/ X-Received: by 2002:a17:906:691:: with SMTP id u17mr3292390ejb.337.1620294097830; Thu, 06 May 2021 02:41:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620294097; cv=none; d=google.com; s=arc-20160816; b=OLGscbh2t8IGZdmMoCX4RBqHxGm5YDT0KYsVtSfz7w00T+ELRlam7lN8LWzA3sNLsc f5nOVAtrnZAjNQP388kRnovQOCqpk8FUKW2afwG2K2z47LBIdZReeRnSpeHYSR1wMqVK 3wV9TzBCJ2uFJkloKILNQPVJqFlDT9g9CHwRriH4zwGNFX1bBtGCDxCs8evkCCFYb70M iGzYlqdSMUh5YhvX/1bpjcN4LHEyOO6N7L5r9a27dt3EHp4PNlnAVUDAMdmoxdxJwmm1 qhkbIUIpf47Gpth2qdic2kBhwoBYkfGlPfnKBxKPnDGKAgRSMTIsrYveNkmP8iDGueu7 H/Yg== 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=QIjjVRAepUz0tUlp/tZGcnwPOve84w6LtIWextnYx/E=; b=m+VxdkvcKSC2zB2LhXhdgS7+vI7hzovsdHGnn5aHIcMdeUJJJBQH6OYV1NT1Q4JihN jpmIYL8t54Jqcn9a8Nos3Z4ZciAmBRivfLe+sG0x96b4K1IS9IrGeoHj0O7O6TIm+Bli tSZo1wbrw6K6Vqmx6LiPO/JJd3A5WAEdKh4+ca1lcsjft6ewb3gbeLyiJF0SU9YTx/CM cqGIRlPxlkb8eHz4Oivay9kkxYKIekCCKc7RaTAfaL5uHFVRzk1N04JMy9Cf6LEiWWMu vj7oJe+GNSZu+B7QRbOhyHehTDgD3x3Gk79RaoCoYoZQHUlxh2FoJ3URUoC3rBG6mNfi A6XQ== 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 m25si1801951edr.235.2021.05.06.02.41.14; Thu, 06 May 2021 02:41:37 -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 S234120AbhEFJc5 (ORCPT + 99 others); Thu, 6 May 2021 05:32:57 -0400 Received: from 8bytes.org ([81.169.241.247]:37654 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229698AbhEFJc4 (ORCPT ); Thu, 6 May 2021 05:32:56 -0400 Received: from cap.home.8bytes.org (p5b0069de.dip0.t-ipconnect.de [91.0.105.222]) (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 73639379; Thu, 6 May 2021 11:31:56 +0200 (CEST) From: Joerg Roedel To: Eric Biederman , x86@kernel.org Cc: 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 1/2] kexec: Allow architecture code to opt-out at runtime Date: Thu, 6 May 2021 11:31:21 +0200 Message-Id: <20210506093122.28607-2-joro@8bytes.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210506093122.28607-1-joro@8bytes.org> References: <20210506093122.28607-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 --- kernel/kexec.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/kernel/kexec.c b/kernel/kexec.c index c82c6c06f051..d03134160458 100644 --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -195,11 +195,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; -- 2.31.1