From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 58BC63290DE for ; Mon, 23 Mar 2026 18:59:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774292391; cv=none; b=LdbkW3KZYAnqEU53jKYl3xFBGwaTgLB2LT78EFdWmm2mXyEni9cjQDyyYkvt7yyeqTlvIE7M4pxXKibNj1fjr2ME51k66GKyrC2dL1rrQxh60ZVcMJvl2GLX6KcRNlBnDO7etsAMunz15/o2OIg5AVdxN05gMRyRWa5TqKQYpbU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774292391; c=relaxed/simple; bh=R/aFwRl42vOjeMU9REVlp4PXzXmXuk8i1nzqTLN9RVo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=iJ0fBk5RDQqrUNl9NvRgdxDJmdoSEnzZ57ucbPHCepVKX51YwTGL+XxIC66rlvEuEUXEqQnTTgJ9VUdkBcT0njqpKbGecXip1GuPwZodZmWsfzrGyUVMtZ5qTNdFUBLTp/r3eIU3iLmS27MqmZwx3G/ZBmBvWAu9212MrsmUMrM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=HzAo17Ow; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="HzAo17Ow" Received: from [172.27.2.41] (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 62NIhE042964862 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 23 Mar 2026 11:43:15 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 62NIhE042964862 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026022301; t=1774291396; bh=xQtRB4/JcUROOuOO8F6Foow7+K/KTfklM2ZeSg79Hy4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=HzAo17OwOnTKR2Qgnu14xeA+ss2M2VbZOk5yICb3kbZn+e5tS5puoL8hGx7g6b8rl vwTIex4BUIGVSitfb9UDlMaD67Zt9JjN178jWHA3fiBlM2332iFdGeRnpu8ukyxqG2 VAs4maVN2S0uLaSh+EGLPEdBPgwJZ7Mvm0am70tzXuh8hByC+oMDoTGIhhSZMNPf3s vchcsgl6vRv1opfP1W3zd+QFh4mQzzFIoT+75uZtwZJ96h2TltIHvUa3T3H1FGe2rD TwhnvDTZxlt4UqGets/K6K3y3cpUV4LYYDpLGdzI/WT5rzOAFW/3rFreCOeHfU7l/D amN4aBcZEqQyA== Message-ID: <207ba0a6-5ebc-465a-8d54-6e5a99622a72@zytor.com> Date: Mon, 23 Mar 2026 11:43:08 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 3/4] x86/cpu: Do a sanity check on required feature bits To: Borislav Petkov , Maciej Wieczor-Retman Cc: 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 References: <7312c9f2feab8aea4612ed9a1841e8c22f5f69b1.1774008873.git.m.wieczorretman@pm.me> <20260323163145.GGacFq8WW0t2uqZm91@fat_crate.local> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: <20260323163145.GGacFq8WW0t2uqZm91@fat_crate.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-03-23 09:31, Borislav Petkov wrote: > > AFAICT, if *any* of those features are not set, the machine will crash'n'burn > anyway. > > So the required features will be "enforced" pretty early :-) > > Otherwise they're not really required. > > And besides, what's > > arch/x86/kernel/verify_cpu.S > > for if not for that? > That is not necessarily true at all. As such, this may be a really cheap way to get a message out in case we get that far without problems. 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. 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. Finally, as Maciej reported, the user might have tried to explicitly override a required feature. 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. verify_cpu.S is unfortunately not able to issue messages (not to mention that it is written in assembly, *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.