From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-139-mta228.mxyeet.net (mail-139-mta228.mxyeet.net [23.172.139.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A97E298CA3 for ; Sat, 4 Jul 2026 18:20:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=23.172.139.228 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783189228; cv=none; b=NDTXFXqnkuH0VIPZdMwtSunXO32roc/VK616ucoDhP7ydW+sLfVZ82UI4Ak0EzZG1njgWPQM4yfflf+Mex0tEaDzHMgU2VL41/KNtVgaToCZSBiAk7RazgJx6A5xFdkzQR81bMU60U6rtdt0ZCgNp6yiyToXUCRe6ZIrBm9ENic= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783189228; c=relaxed/simple; bh=zFimLLHEOeISBiUpfFEkoyW9wAJx3PTGok0CFh19j6s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Avxsqzi+OVf6SUTJyAtvWEu1tJ1ckvNXklgPjGnt5elWFqrfumEC2GGQmiA5QEo6yKng/zbknEcXvlJ/94Bll/V9HKLItcsd96RXFsdwS48wHgkhqfA71FWEgfyWGX7nv7KJ1qW8JggZbA7czTe+2IiPGVXjpM3//MWImu2TQBQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=evalyngoemer.com; spf=pass smtp.mailfrom=evalyngoemer.com; dkim=pass (2048-bit key) header.d=evalyngoemer.com header.i=@evalyngoemer.com header.b=fEM+d4FM; arc=none smtp.client-ip=23.172.139.228 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=evalyngoemer.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=evalyngoemer.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=evalyngoemer.com header.i=@evalyngoemer.com header.b="fEM+d4FM" Received: from us1.workspace.org ([162.244.93.81] us1.workspace.org) (Authenticated sender: smartermail.us1@mxyeet.net) by mail-139-mta228.mxyeet.net (MailFilter Outbound) with ESMTPSA id 19f2e5776b3000d9a4.009 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 04 Jul 2026 18:15:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=evalyngoemer.com; s=cx8DDCB0BEEEDC8F5; c=relaxed/relaxed; t=1783188911; h=from:to:cc:subject:date:message-id:in-reply-to:references:mime-version; bh=i2KktWDf52JWk3Kz0mnoCQ0URp+srXh/JDxgOMnCnww=; b=fEM+d4FMBcODRNzwk4aAG9gAGaCdpbhLASS0LiDxVWEXeFVIXekiyglAysial+4MvEKdvaDY7e3 kordYCEyjwM42yR2J85ihmBAgpqcxaG7wmvVfwD00mbAi8tXXb+u2dsflP7iI/tr18x9XHMzpLUDg GpTCLLBV6ImYCFfbk/1CrdngsbDlSI20jOfzFzLohDDwGJQRAump1iQk3Nt/JErQY57VRHYfMc/sM HObg/w/UckJwpVaEiO5RYWWb/rjSZ+vhWE4wamgJhYxe/mVA4iW4WnnYy1dktUdtCiEe/tbFNR6bl 9LGJoiFKqEi+Ns94LWr5IVQp1STHO1xaBFuw== From: Evalyn Goemer To: ludloff@gmail.com Cc: linux-kernel@vger.kernel.org, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, joe@perches.com, Andrew Cooper Subject: Re: [PATCH] platform/x86: handle Intel CPUs falsely reporting as GenuineIotel Date: Sat, 04 Jul 2026 14:15:02 -0400 Message-ID: <31nKPXtCQwaVciQ3mSoYDQ@evalyngoemer.com> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Saturday, July 4, 2026 1:00:20=E2=80=AFPM Eastern Daylight Time Christia= n Ludloff=20 wrote: > On Sat, Jul 4, 2026 at 11:46=E2=80=AFAM Evalyn Goemer wrote: > > On Saturday, July 4, 2026 4:22:40=E2=80=AFAM Eastern Daylight Time Chri= stian=20 Ludloff wrote: > > > > https://github.com/InstLatx64/InstLatx64/blob/master/GenuineIotel/G= enu > > > > ineIotel00306C3_Haswell_CPUID5.txt> >=20 > > > The InstLatx64 dump remains the *sole* full ("canonical") report. > > > The additional two known *partial* reports (SNB and IVB) are here: > > > https://web.archive.org/web/20251105144105/https://valid.x86.fr/kjm24i > > > https://web.archive.org/web/20250221003721/https://valid.x86.fr/5f6gzf > > > It is possible that the reports were tampered with by humans. > >=20 > > parroted around in many places >=20 > Yes, cited often... but they all trace back to that single HSW dump. Yeah that is quite odd and is why I have tried to contact the person behind= it=20 to see if more can be found about it. Along with my friend and maybe others= =20 checking chips to see if this can be reproduced this could maybe be replica= ted=20 to get other sources properly. >=20 > Beyond that one, there are those sole SNB and IVB reports... but > those lack details... and the same single bit flip on 3 uarch gens... > is rather unusual... and I've seen quite a few things in my x86 life. I did end up looking through the site you found the partial reports on and= =20 found 5 other reports that have a bunch of haswell chips reporting this. https://valid.x86.fr/i75p6c https://valid.x86.fr/gq5kl4 https://valid.x86.fr/84i82r https://valid.x86.fr/fqwjgq https://valid.x86.fr/vh4mjs As well as probably one of the stranger sources of this being a random post= on=20 a Chinese message board where when expanding the full question it shows a=20 "GenuineIotel" on their hardware listing. While it could be a typo it also= =20 happens to be a haswell series xeon which matches up exactly with other=20 reports. https://web.archive.org/web/20260704102753/https://zhidao.baidu.com/questio= n/ 373506097973561924.html >=20 > Overall, it's an outlier, and I'd flag such systems, not placate them. Yeah it's a very strange thing I have found and thought could be worth=20 handling. I ended up making the patch this way since this is the only case = of=20 this I could see as well other codebases online handled it similarly. The=20 other reason I did it this way was to keep it simpler since it used existin= g=20 mechanisms and not need something much bigger if it wasn't needed. What do you think is a better way of handling these kinds of quirks? Maybe = a=20 quirks table of known bugged vendor strings that resolve to the correct ven= dor=20 and print a log noting that its specifically bugged and assuming the proper= one=20 versus it just saying it's fully unknown and not detecting proper. I would be glad to make a proper v2 patch that did proper handling of this = if=20 you have suggestions on how that should be done. >=20 > -- >=20 > Fwiw, I also question the existence of "AMDisbetter!", reported for > early AMD K5 samples =E2=80=93 I have FMS=3D500h parts, and they report > the "AuthenticAMD" string, as expected. If anyone got proof to the > contrary, let's see it please. :-) There are a lot of things reportedly found in CPUID that could have not bee= n=20 real or just have been something else including things like the "AMD prank= =20 leaf" being at "0x8FFF_FFFF" according to sandpile.org which has a similar= =20 issue of not many sources elsewhere. It would be nice to be able to find more of these CPUs to test them across = a=20 wide set of boards to see what triggers these and if they can even be=20 reproduced at all. Maybe even better find out how these started out being=20 spread online. >=20 > -- > C.