From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) (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 79A3A30FF2E for ; Thu, 22 Jan 2026 13:50:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769089842; cv=none; b=UfJreISFb+whYCSBZ57uXPVqyIVPQtVtanXsORLMyXcrogZ8CL7NCFg63MsBIYc42STesk5MvyGodvDrVCi+ubhxQ3ylU9x6nEPb+KGI9RnUYsmv5Grh45sMnY4I+Qdy2lO51JaMwvJzWEJqRwXCx9GmC1LiKq6nRQRIPynRvcI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769089842; c=relaxed/simple; bh=9o+HRKz69DFHO8DP9QTbb6eOLSzzltQysI1LahYLqLY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EoFG869CANQfmxKEW7ja4Cw8U5fBhVUs5kc9+cveAd6ZS8BnH6ZS4e2Z488qc2Gsbhs9brr6mRzkVhEnYNV4JFuRC3WIzhombnawNcTVX+djc4N09T32gFZVLhSLjAqhEdckd05Iam5lbz+4rzRxxMnNNhXf6/d83LKjBTCQWX0= 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=BRDmwD+C; arc=none smtp.client-ip=198.175.65.15 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="BRDmwD+C" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1769089841; x=1800625841; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=9o+HRKz69DFHO8DP9QTbb6eOLSzzltQysI1LahYLqLY=; b=BRDmwD+CKUdLK2yLLV6EicI40/KIl4kZIsUFSJs3F0ZryrAMvXz6fIiS h/7AP3YuUM7wvWxYR8vTC/jwkbMCaxdSW+qmH9pjXvXy7gjFHMfMN6iQ/ c35yXwFvRBUj2p9hbLfcszTSR+GvC2BboAfJU4VxyCS0IF6z6nyJRYXO4 du8dHGSSP4a6EA1BFDpCznaRCtMOF4A9a643RiIBv7973OSr07+yoK8aa k4XgeS10ZBrsRq2cI3S1d6vpfG8YIuALLf+0Iqzrq0NudaR+Ro0iQNsPx ih6oEO85AwZw5lLAn6Gs5JDn3mcG7xvq2hdz4HjKU33NLCGSA19NdTvti A==; X-CSE-ConnectionGUID: TJ34RmpDQ/qWvNSVWIYR3A== X-CSE-MsgGUID: 7UZhGpLiSJm7dYYsjeghgg== X-IronPort-AV: E=McAfee;i="6800,10657,11679"; a="73958386" X-IronPort-AV: E=Sophos;i="6.21,246,1763452800"; d="scan'208";a="73958386" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jan 2026 05:50:40 -0800 X-CSE-ConnectionGUID: wNc7oGTLTuC7AGFe8e6bfg== X-CSE-MsgGUID: Xju+sSQATduOZBAyujy60g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,246,1763452800"; d="scan'208";a="205990734" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orviesa010.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jan 2026 05:50:39 -0800 Date: Thu, 22 Jan 2026 05:56:55 -0800 From: Ricardo Neri To: Dave Hansen Cc: linux-kernel@vger.kernel.org, sohil.mehta@intel.com, Borislav Petkov , "H. Peter Anvin" , Ingo Molnar , Jon Kohler , Pawan Gupta , "Peter Zijlstra (Intel)" , Thomas Gleixner , Tony Luck , x86@kernel.org Subject: Re: [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks Message-ID: <20260122135655.GA17795@ranerica-svr.sc.intel.com> References: <20260119195047.86E3C696@davehans-spike.ostc.intel.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=us-ascii Content-Disposition: inline In-Reply-To: <20260119195047.86E3C696@davehans-spike.ostc.intel.com> User-Agent: Mutt/1.9.4 (2018-02-28) On Mon, Jan 19, 2026 at 11:50:47AM -0800, Dave Hansen wrote: > There was a report[1] that CPUs running updated microcode were being > reported as running old microcode. The reason is that the old > microcode list neglects to take the platform ID into account. > > The platform ID is an Intel-only construct that allows CPUs that > otherwise have the same model/family/stepping to take different > microcode revisions. The microcode loader itself already checks this. > Only the recent "old_microcode" checker failed here. > > Treat the platform ID as a peer of model/family/stepping. Store it > in 'struct cpuinfo_x86', enable matching on it with with 'struct > x86_cpu_id', and flesh out the 'old_microcode' list with it. > > This fixes the report of an inaccurate, false positive in the > 'old_microcode' vulnerability file. > > 1. https://lore.kernel.org/all/38660F8F-499E-48CD-B58B-4822228A5941@nutanix.com/ I tested this patchset on two machines: Alder Lake (F-M-S/PI = 06-9a-04/80). The microcode-20251111 from Intel lists different versions for platform IDs 0x80 and 0x40 of 06-9a-04. Before these patches, only the machine with platform ID 0x40 would have falsely complained about the old microcode. Mine did not, as expected. I applied this patchset and tweaked the file intel-ucode-defs.h to fake a later microcode version. I could verify that my machine was identified correctly and distinguished from 06-9a-04/40. Kaby Lake (F-M-S/PI = 06-8e-09/80). There are two platform IDs for this model and stepping, but the latest microcode for both is 0xf6. Neither of these processors would have reproduced the reported false positive. Again, I tweaked intel-ucode-defs.h with a fake .data_driver value and could verify that my stepping and platform ID were identified correctly. Tested-by: Ricardo Neri