From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 A54B94C955F for ; Wed, 8 Jul 2026 18:40:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783536040; cv=none; b=eo40738YhcRbtgE1RDWrLAus5MX6dYZE6RgAlgdJMg618a4yLAkLJ73Wd5RSxIWylOE/Oougn6EzIgbKCnmQVjtiAT2MaB/ENurDpN0bF88ti7nultIKlG3rd8vyqe/7mPteXCbrAzrJsXhEPBoloYNNDD5NLPGHhET1sSKY3Pk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783536040; c=relaxed/simple; bh=UQHgaGLz04aE1vgCe12rESh8hEnwX6rUhBlMSp4x0yE=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=SwRp0ZBkh5rcz11KGb/25sRlO3Cdv8bP0CS6Kv4VF/dPH2MPhYVNgLuwsdAhML165kWXuwoa5ydlyjtzG139/d2b5A5+PX4Cl7wsbMWe9sF376jzfn8W6y4hP4LytZBH3bjc10NTgqGOlnI41WqDLWmZQaEqblBn07Ig0yQu+cs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=l/WSp/iY; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="l/WSp/iY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1783536036; x=1815072036; h=date:from:to:cc:subject:message-id:mime-version; bh=UQHgaGLz04aE1vgCe12rESh8hEnwX6rUhBlMSp4x0yE=; b=l/WSp/iYV4u2fyWB02D9wnV9bobiyk91MP+QIc/Wu2rOXXiwUru8MiGt 8f1l1so+0gblrDrwzLYq8s19si9UnKriP6orKXbWDqXsvDwdO+14wJX2/ i36bLhn11HxzrjF/+ttXJpBE17W7bG8SNeJlLYYwAOJljFPiZbJzd+4pq bK00ct+zRGiqtjPrw1fljEKkzllodd7ZwvvFAc/DxGyqOqDS7OzMVACvU 4DJegTIbkRMu/UD7/SQEYp9AZkqWmwEqkGOwsm6xDsAD3tZg5j45Ce64N l+XaJvByCZmLu3AxL/Ptb47IofeCcpjuYs/ngkfFHUpK7ufotaGg0c6tI A==; X-CSE-ConnectionGUID: vcEahIBoQouShxmqpY6LpA== X-CSE-MsgGUID: L0V+N1xlTzO62x937ZRCoA== X-IronPort-AV: E=McAfee;i="6800,10657,11841"; a="88035439" X-IronPort-AV: E=Sophos;i="6.25,153,1779174000"; d="scan'208";a="88035439" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jul 2026 11:40:35 -0700 X-CSE-ConnectionGUID: E1MgPIgLSVOtv/PJe7NrYg== X-CSE-MsgGUID: wkaYE9jUQmeyMsPFr9dwug== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,153,1779174000"; d="scan'208";a="253884148" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jul 2026 11:40:34 -0700 Date: Wed, 8 Jul 2026 11:40:14 -0700 From: Pawan Gupta To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" Cc: linux-kernel@vger.kernel.org Subject: [PATCH] x86/bugs: Don't use cpu-type matching in cpu_vuln_blacklist Message-ID: <20260708-cpu-type-vuln-v1-1-85c1d3c704db@linux.intel.com> X-B4-Tracking: v=1; b=H4sIAPGYTmoC/yXMQQ5AMBBA0avIrE1SIiquIha0gxGpplUh4u6K5 Vv8f4Enx+ShTi5wtLPn1URkaQJq6sxIyDoacpGXQooKlQ24nZZwD4vBrNCk5aCELiTExjoa+Ph +Tfvbh34mtb0TuO8HLtSppXEAAAA= X-Change-ID: 20260708-cpu-type-vuln-14ded7fc0d47 X-Mailer: b4 0.16-dev 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=us-ascii Content-Disposition: inline Thomas Gleixner pointed out that cpu-type is a per-CPU property while hybrid is a system property, conflating the two in the CPU matching infrastructure is wrong. Currently, on a hybrid system x86_match_cpu() matches any cpu-type. This works if the intent is to find the possibility of a cpu-type in a system. But fails if matching for the cpu-type of a given CPU. Borislav posted a cleanup here: https://lore.kernel.org/all/20260703193222.GFakgORjvxwnZTPRnI@fat_crate.local To make way for the cleanup stop matching cpu-type in cpu_vuln_blacklist. RFDS is the only user, so drop the VULNBL_INTEL_TYPE entries and fold their RFDS bit into the base Alder Lake (0x97) and Raptor Lake (0xB7) blacklist entries. For now open-code cpu-type check in vulnerable_to_rfds(). In future, if more vulnerabilities need cpu-type matching a helper can be added. No functional change intended. Fixes: 722fa0dba74f ("x86/rfds: Exclude P-only parts from the RFDS affected list") Signed-off-by: Pawan Gupta --- arch/x86/kernel/cpu/common.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index a3df21d26460..b38126199a5b 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1251,9 +1251,6 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = { #define VULNBL_INTEL_STEPS(vfm, max_stepping, issues) \ X86_MATCH_VFM_STEPS(vfm, X86_STEP_MIN, max_stepping, issues) -#define VULNBL_INTEL_TYPE(vfm, cpu_type, issues) \ - X86_MATCH_VFM_CPU_TYPE(vfm, INTEL_CPU_TYPE_##cpu_type, issues) - #define VULNBL_AMD(family, blacklist) \ VULNBL(AMD, family, X86_MODEL_ANY, blacklist) @@ -1316,11 +1313,9 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = { VULNBL_INTEL_STEPS(INTEL_TIGERLAKE, X86_STEP_MAX, GDS | ITS | ITS_NATIVE_ONLY), VULNBL_INTEL_STEPS(INTEL_LAKEFIELD, X86_STEP_MAX, MMIO | MMIO_SBDS | RETBLEED), VULNBL_INTEL_STEPS(INTEL_ROCKETLAKE, X86_STEP_MAX, MMIO | RETBLEED | GDS | ITS | ITS_NATIVE_ONLY), - VULNBL_INTEL_TYPE(INTEL_ALDERLAKE, ATOM, RFDS | VMSCAPE), - VULNBL_INTEL_STEPS(INTEL_ALDERLAKE, X86_STEP_MAX, VMSCAPE), + VULNBL_INTEL_STEPS(INTEL_ALDERLAKE, X86_STEP_MAX, RFDS | VMSCAPE), VULNBL_INTEL_STEPS(INTEL_ALDERLAKE_L, X86_STEP_MAX, RFDS | VMSCAPE), - VULNBL_INTEL_TYPE(INTEL_RAPTORLAKE, ATOM, RFDS | VMSCAPE), - VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE, X86_STEP_MAX, VMSCAPE), + VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE, X86_STEP_MAX, RFDS | VMSCAPE), VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE_P, X86_STEP_MAX, RFDS | VMSCAPE), VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE_S, X86_STEP_MAX, RFDS | VMSCAPE), VULNBL_INTEL_STEPS(INTEL_METEORLAKE_L, X86_STEP_MAX, VMSCAPE), @@ -1388,7 +1383,21 @@ static bool __init vulnerable_to_rfds(u64 x86_arch_cap_msr) return true; /* Only consult the blacklist when there is no enumeration: */ - return cpu_matches(cpu_vuln_blacklist, RFDS); + if (!cpu_matches(cpu_vuln_blacklist, RFDS)) + return false; + + /* + * ADL and RPL are affected only if they have Atom CPUs. Hybrids have + * both Core and Atom CPUs. Mark unaffected when Atom CPUs are not + * present. + */ + if ((boot_cpu_data.x86_model == 0x97 || + boot_cpu_data.x86_model == 0xB7) && + boot_cpu_data.topo.intel_type != INTEL_CPU_TYPE_ATOM && + !boot_cpu_has(X86_FEATURE_HYBRID_CPU)) + return false; + + return true; } static bool __init vulnerable_to_its(u64 x86_arch_cap_msr) --- base-commit: 8cdeaa50eae8dad34885515f62559ee83e7e8dda change-id: 20260708-cpu-type-vuln-14ded7fc0d47