From mboxrd@z Thu Jan 1 00:00:00 1970 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 C632A339719 for ; Mon, 23 Mar 2026 19:19:37 +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=1774293579; cv=none; b=am5bYJNcnrOXF2zzH+8VJCp4je4ZNVRxFEjjYOvtk54BR7BLcSJ7C51APsy2T+iKhej0frFVh1y8OMe5YETzvOjInxokyvzp6PLPPsFoTztXWsg0m0nfiwLDyjr/9hyAmUs6u18Dn1yl/lv3d/yJ4tEj834I89BEjg8SM/i5hes= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774293579; c=relaxed/simple; bh=W+74RfTrNFTPmvM/ug/Gs4wNiBnmvuD0zdQelf8hkPM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=B/AcZPMaYBAJOGNVW6NgLFPiNqSGTrRbHBpTtZMiGg9s68bWn0n6Fkxqyo1tdjnnc6Kgoty9To3wxiWDLWBeASN4XWiFhEIzBx3My4MaC2YdNiQ/bSoxFNdC1NRl/iR74QA2WoI14n42eWKu3MK+VTeTPqrcxHI7F8iFLXilKCo= 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=pass (4096-bit key) header.d=alien8.de header.i=@alien8.de header.b=BO+P41uU; 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (4096-bit key) header.d=alien8.de header.i=@alien8.de header.b="BO+P41uU" Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 8438940E019D; Mon, 23 Mar 2026 19:19:35 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) 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 Pxy4lbv0zbp8; Mon, 23 Mar 2026 19:19:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1774293570; bh=aBpRR8DQkDpX0Q2CLJ2hba1Gzg4oG6xShxmqpOFMl0E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BO+P41uUIhGnOTZfp07ndWKqLp7SeWRGeJLB3+yL37QQA/yIDIphqr9LGM1EHPA1E Z/3rQCzMKNCgwpKt8xnGdd9lUXb4UoxbdclOVLGAcV4JhFCCk/zriRDMpsCCs/eOsW OWEAqplrnywcl5mXZATnWk/1e/OCrxitAVN1YCrK8Dtv1Rqmvo9DX61eeJE8b3+XB1 bd2IIqGif3Omm6uDRk9CedC1R3X919o3hK72Y+joYe5y48LfL1nyJ8TN164EYdUp2q yQQSZ+3AwbgAiwn7s3+UW3/LOv1jC804R+JoKHxROazWldQCU8+6SxnmkDM+y8hOxZ H8RfJgVrZkeCFpG4I7a2+Zwb3K8RXUzm04q7cWj/8d2882aPQ2MKtueKslxvUkO3tL K7wCo04AZc3bfY7mt7G5QC+GgCS2ZNchJxNQMtjnszv4jyzW2eSIGjt6RjTimdN3qt sJyN3PJ8p4HMf2Nvco9TtNhpXzKTU6VY+74UNxfZIr0bZQ9/oISUvvLDZ0izCrGePk iNacY67I4wk3XyJT/yjWDLTbFGCCx0sDgU0XhuQMevuF1Xj5YK49hmrPSpyU5SsHHC IDu/H12ZicKBshQEy5eM0QW4V1WQJOqK/hLip4ivsmMkw7EkkiC0lg/Bei1vh45T0/ m97FO2OO+zUPM7VQM3QxFTl8= Received: from zn.tnic (p5de8e020.dip0.t-ipconnect.de [93.232.224.32]) (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 UTF8SMTPSA id 5428040E0194; Mon, 23 Mar 2026 19:19:12 +0000 (UTC) Date: Mon, 23 Mar 2026 20:19:05 +0100 From: Borislav Petkov To: "H. Peter Anvin" Cc: Maciej Wieczor-Retman , tglx@kernel.org, peterz@infradead.org, xin@zytor.com, maciej.wieczor-retman@intel.com, babu.moger@amd.com, chang.seok.bae@intel.com, sohil.mehta@intel.com, dave.hansen@linux.intel.com, jpoimboe@kernel.org, elena.reshetova@intel.com, pawan.kumar.gupta@linux.intel.com, ak@linux.intel.com, darwi@linutronix.de, mingo@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v11 3/4] x86/cpu: Do a sanity check on required feature bits Message-ID: <20260323191905.GDacGSKaG4rEU8O4NA@fat_crate.local> References: <7312c9f2feab8aea4612ed9a1841e8c22f5f69b1.1774008873.git.m.wieczorretman@pm.me> <20260323163145.GGacFq8WW0t2uqZm91@fat_crate.local> <207ba0a6-5ebc-465a-8d54-6e5a99622a72@zytor.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <207ba0a6-5ebc-465a-8d54-6e5a99622a72@zytor.com> On Mon, Mar 23, 2026 at 11:43:08AM -0700, H. Peter Anvin wrote: > That is not necessarily true at all. What does that even mean?! :) > As such, this may be a really cheap way to get a message out in case we get > that far without problems. Meh. > For one thing, this runs -- at least on the BSP -- before either alternatives > patching or running user space, so there is plenty of features that may not > have been used yet. We're talking about required features here. What's wrong with verify_cpu() testing required features and stopping if some of them are not present? It is already checking some of them. > For another thing, there are some features -- such as PAE to mention one -- > that are present in some CPUs but disabled in CPUID because for some reason or > another the manufacturer found during testing that it doesn't always work > right. However, it is likely that a PAE kernel will successfully boot, and it > might even work on any one particular CPU. This is *exactly* what > TAINT_CPU_OUT_OF_SPEC is supposed to represent. And? We're supposed to support such a CPU or somewhat wobbly only? You want to be able to boot up to the point of checking required features in C code, find out that PAE is not supported, taint the CPU but still run? What for? How do you explain the user that her machine is actually fine but we'll taint the kernel and that it maybe works but maybe not and there are no guarantees? > Finally, as Maciej reported, the user might have tried to explicitly override > a required feature. You can still catch it in verify_cpu. Catch it such that you simply stop there. If the luser is overriding required features, then she gets to keep both pieces. > verify_cpu.S serves a different purpose: is to enable features that are > required to even set up the kernel execution environment and that may be > switched off through various mechanisms. And because we run it at so many places, then it can do those checks for us too. > verify_cpu.S is unfortunately not able to issue messages (not to mention that > it is written in assembly, We can convert it to C. We've done this before with other crap. :) > *AND* it doesn't have access to all the rules and exceptions that are coded > into arch/x86/kernel/cpu/*.) There *is* a messaging function in the BIOS > stub, but there is no equivalent in for code that bypass this stage (which > is of course standard these days.) verify_cpu.S just returns a single bit, > and that only represents checking for a few very basic features. Yes, I have seen the error message about this CPU not being supported very early. But I don't see the point for adding another function to verify required features which is somewhere else where we're pretty much doing that checking early. And what's the point of booting up to C code and kernel proper and say that some of the required features are off? I think we should extend verify_cpu or convert it to C or have it call a C function or whatever and do the checking once and for all and not boot into a wobbly and tainted kernel. As to showing a proper error message, what is the real use case we're chasing here? The CPU has all the required features - which is probably 99.999% of the cases out there or it doesn't and then it deserves to blow up. So what are we really "fixing" here...? Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette