[RFC,1/2] Revert "x86/kexec/64: Prevent kexec from 5-level paging to a 4-level only kernel"
Message ID | 20240301185618.19663-2-bp@alien8.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-88970-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:fa17:b0:10a:f01:a869 with SMTP id ju23csp88433dyc; Fri, 1 Mar 2024 10:59:35 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXM+3MfSr7dKzC2xJ038yLhSD47aHhSDeyn192pqxCUYV+Yez67Z2CYNAqQDERSUP9+tiLkOqKkk2dRrBq9BZGldcdYcA== X-Google-Smtp-Source: AGHT+IF/gdUCB21wK57bCCVDgEpAFHJ32ZvC894NrivoZlsJ6s53SXkHBxgXeCDVsf4GO7HMd1tw X-Received: by 2002:a05:6808:1189:b0:3c1:c2a5:ca55 with SMTP id j9-20020a056808118900b003c1c2a5ca55mr2862423oil.55.1709319574937; Fri, 01 Mar 2024 10:59:34 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709319574; cv=pass; d=google.com; s=arc-20160816; b=x55Vp59owuCqlkqoPdV6n5G87hRG3JxOT2fVFS3WdY+kzbnfyyoyMs7Lhh+CJufAG5 uukaDsuMbdyuV3xdrla2gmJ2yUlvA8XHmqXYJ1gjPkkhFzWzFFty/MILOs8LVLrSoSMD TAu4GMezmg7fz+ZcHSzHAfTjqOxLx/bJ3zV1nL3fOSj74C+CVg+HMLM0CE6hLhLlxvun fkF8SVVnc4ACpVSpvwiWCnY1slcMIItCzESvhtczHMm2819l9sgbR6L6aFSIZ18Su9Sw Ay+ydIUr1YPKGsnOj6cemlzfuUoPAM4eV8YNBsoQBzrpKwlQxJOABs8z2eBInN9/X0hZ lE3A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=NCDKzhfJfDqmI5GokSSN+ljSg9VRHtGFFqA8HBDO79s=; fh=GAWDeZ8GLPZlCoEE1g14GdP0AZ4w9Et1LYAW9OtWjwI=; b=s3EXSmeCUJzTv42ZhA/WilruJMxaMrJ8XJoZ/rmIOJwRB2E32jiwir4kBdTAOImsx2 H3tevgoHJ5j3tWzUaPr1i+Y+JL4O69iMuaXXVhoaBczoJyHlCJZEatjy8y0Tfla17oUz fqBKrtxiAOLa7oDn9JrluyMtJtUs+EIGa8N9dJdeaZDMDYKZMC3Ov5fJiIcK1AELI/6D mnmaCiVW0ik87AbxSFa2sxVAy03DONEvIUinkA7y95wwcAHq3jcQ4NBNqfud93eWpaCd zcfMP3oDc6B45Du64BUE/xAZh5f1THdE/NbN45Twdge5sXmGZiyBOFvgrhfI4V5/uyRD sY4Q==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=neutral (body hash did not verify) header.i=@alien8.de header.s=alien8 header.b=gT5c9ixn; arc=pass (i=1 spf=pass spfdomain=alien8.de dmarc=pass fromdomain=alien8.de); spf=pass (google.com: domain of linux-kernel+bounces-88970-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-88970-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id d14-20020ac8544e000000b0042e808c4b11si3813010qtq.784.2024.03.01.10.59.34 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 10:59:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-88970-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@alien8.de header.s=alien8 header.b=gT5c9ixn; arc=pass (i=1 spf=pass spfdomain=alien8.de dmarc=pass fromdomain=alien8.de); spf=pass (google.com: domain of linux-kernel+bounces-88970-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-88970-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id B0DEE1C238AA for <ouuuleilei@gmail.com>; Fri, 1 Mar 2024 18:59:34 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B70513F8D3; Fri, 1 Mar 2024 18:56:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (4096-bit key) header.d=alien8.de header.i=@alien8.de header.b="gT5c9ixn" Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D0803D548 for <linux-kernel@vger.kernel.org>; Fri, 1 Mar 2024 18:56:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=65.109.113.108 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709319400; cv=none; b=NdjvCytCdDKBH0f0cN7g7Y1Lb6o106B01Q7t1pnqBtvVhngLe+fDpJop72AIzpO6cFwTvcBAmvzqNlCVYxkyJ5zf0HmAlRdcRZn+QSu8WcLNcnp57+X9byImLApd6Q3J0roi1Y9XkgOG7KrpTVgbH8ix5sqK+3QOvub2bh6sa/k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709319400; c=relaxed/simple; bh=k5E4WWGp+V+degHNN7v/pKAtVxC2pZvmpVUXfqdSfPE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G3GF5xiRU4APKjZJmsseA48x9Pxd00hF3sfDHujNlTM38sFX8O1TYVfNxe1pGMjX1rcHsV6C06yMNvhmypMFmyRqq0pjQK0Hs7do6RCx3xWD6HybbBa7EFYGQkXCKeuyJyl8QNfoLCjhASPElQsZhU4dSiwJtZxBgOkA3PnhbHM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=alien8.de; spf=pass smtp.mailfrom=alien8.de; dkim=fail (4096-bit key) header.d=alien8.de header.i=@alien8.de header.b=gT5c9ixn reason="signature verification failed"; arc=none smtp.client-ip=65.109.113.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=alien8.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=alien8.de Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 834C440E0196; Fri, 1 Mar 2024 18:56:36 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=fail (4096-bit key) reason="fail (body has been altered)" header.d=alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UZe5OO0KE1r9; Fri, 1 Mar 2024 18:56:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1709319394; bh=aN+C2xm0YbEn8nVRyX6/uoOtPGSz1gU4UO9UwrqDSKk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gT5c9ixnrC+Rd0ZGaWzShfz63pxWzWEvv4QAlD6JlDrYbQNyan9DrUHoUgNOs70ql TAjZ5jMimNqGpSvUZGIvaLyiPNHRd/yT31LmtdhlaGvjtY3QUDfFkoYhoMxu35JuD3 Lz6xFxNZpDE0ffEtwWbJi7YZ6VzpCnZLPejeNprKVwgxzcbuCgDuayyFRTsyaCkzSk 4RJrxTavvRVpftkD7x96yyBrQTRoN7uuxpwtuN4/rsx9f/odUjQvInXLTXiENyroA+ /YxYHwYepWM8JFXBIGpNhJ2F/cutx5r4LRJqLFe1M2BkBOi0x59lL/FpXM43vFJSGI tYVrfaONaRixZ3cIcyB3iHWTRY+/E8McHc93tcmEOpYV4qP+hgzMeZcWiF9p+lshf+ MCgG1to6LT5fWpJJUlRSB8XDoXFqFZLfzKS0PlMjeikHXO4X9UIWaoNFikdPebunft Voe5rztrC4oiKqra+gNuAcuF/fc0I2/wBx+j3sHmBFaPsMyiCdpqrZ6ZL+l6wicKNB ob551g2FE6R/z7mBUNicivgzG+fRv9o37YcCYNpt1K6DjJDjKd5qPUAbHJEFyAqHUa Fm/C9GqErAxjUgjV+m+tTKx6vuNddMdbIOeELEAYvYRuJJgKT7rfJ+tlivLMi/3Z0s mjsoW/ySua6TmhYSGVgH+xo0= Received: from zn.tnic (pd953021b.dip0.t-ipconnect.de [217.83.2.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 0A2AB40E016C; Fri, 1 Mar 2024 18:56:31 +0000 (UTC) From: Borislav Petkov <bp@alien8.de> To: Baoquan He <bhe@redhat.com> Cc: X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org> Subject: [RFC PATCH 1/2] Revert "x86/kexec/64: Prevent kexec from 5-level paging to a 4-level only kernel" Date: Fri, 1 Mar 2024 19:56:17 +0100 Message-ID: <20240301185618.19663-2-bp@alien8.de> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240301185618.19663-1-bp@alien8.de> References: <20240301185618.19663-1-bp@alien8.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792351482425467652 X-GMAIL-MSGID: 1792351482425467652 |
Series |
x86/kexec: Revert 5level dynamic switching
|
|
Commit Message
Borislav Petkov
March 1, 2024, 6:56 p.m. UTC
From: "Borislav Petkov (AMD)" <bp@alien8.de> This reverts commit ee338b9ee2822e65a85750da6129946c14962410. This whole dynamic switching support is silly. I don't see a use case where one would use an old kernel with CONFIG_X86_5LEVEL disabled to kexec into. I.e., you use pretty much the same kernel. But I'm open to corrections. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> --- arch/x86/kernel/kexec-bzimage64.c | 5 ----- 1 file changed, 5 deletions(-)
Comments
On 03/01/24 at 07:56pm, Borislav Petkov wrote: > From: "Borislav Petkov (AMD)" <bp@alien8.de> > > This reverts commit ee338b9ee2822e65a85750da6129946c14962410. > > This whole dynamic switching support is silly. I don't see a use case > where one would use an old kernel with CONFIG_X86_5LEVEL disabled to > kexec into. I.e., you use pretty much the same kernel. It's not true. Customer may want to try to load a different kernel if they have taken many testings and trust that kdump kernel, or for debugging. The similar for kexec reboot into 2nd kernel. We don't enforce kexec/kdump to work on the same kernel as the 1st kernel. With the fail and message, user can take measure to avoid that. it's better the failure is encountered when failing to jump to kexec/kdump kernel. I remmeber we have use case where customer used kdump kernel different than the 1st kernel. While I don't remember why. > > But I'm open to corrections. > > Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> > --- > arch/x86/kernel/kexec-bzimage64.c | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c > index cde167b0ea92..4f2e47338b7f 100644 > --- a/arch/x86/kernel/kexec-bzimage64.c > +++ b/arch/x86/kernel/kexec-bzimage64.c > @@ -375,11 +375,6 @@ static int bzImage64_probe(const char *buf, unsigned long len) > return ret; > } > > - if (!(header->xloadflags & XLF_5LEVEL) && pgtable_l5_enabled()) { > - pr_err("bzImage cannot handle 5-level paging mode.\n"); > - return ret; > - } > - > /* I've got a bzImage */ > pr_debug("It's a relocatable bzImage64\n"); > ret = 0; > -- > 2.43.0 >
On Mon, Mar 04, 2024 at 06:51:26PM +0800, Baoquan He wrote: > It's not true. Customer may want to try to load a different kernel if "may want" is one of those hypothetical things which we don't do. If we have to support everything a customer *may* want, then the kernel will be a madness. Also, you do realize that the kernel doesn't care about "customers", right? And the question is, how *sensible* is such a use case? In my experience, not at all. You simply take the same kernel or a very similar one and kexec it. > they have taken many testings and trust that kdump kernel, or for > debugging. Yes, and those kernels will have 5level too. Practically, distros must enable 5level support in their kernels in order to support modern hw. > The similar for kexec reboot into 2nd kernel. We don't enforce > kexec/kdump to work on the same kernel as the 1st kernel. With the > fail and message, user can take measure to avoid that. it's better the > failure is encountered when failing to jump to kexec/kdump kernel. I can't parse that example. Btw, kexec tools don't use those XLF_5LEVEL* flags bits either. Which basically means we don't really need them. > I remmeber we have use case where customer used kdump kernel different > than the 1st kernel. While I don't remember why. See above. And that customer can still use the old distro kernels which have those flags. The point here is, going forward, 5level becomes ubiquitous and will be even more tightly integrated in the kernel so that it'll become just another default feature which is either there or not. So the distinction is going away and the flags can go too. Thx.
diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c index cde167b0ea92..4f2e47338b7f 100644 --- a/arch/x86/kernel/kexec-bzimage64.c +++ b/arch/x86/kernel/kexec-bzimage64.c @@ -375,11 +375,6 @@ static int bzImage64_probe(const char *buf, unsigned long len) return ret; } - if (!(header->xloadflags & XLF_5LEVEL) && pgtable_l5_enabled()) { - pr_err("bzImage cannot handle 5-level paging mode.\n"); - return ret; - } - /* I've got a bzImage */ pr_debug("It's a relocatable bzImage64\n"); ret = 0;