Re: [PATCH] platform/x86: handle Intel CPUs falsely reporting as GenuineIotel

[Evalyn Goemer]

On Saturday, July 4, 2026 1:00:20 PM Eastern Daylight Time Christian Ludloff 
wrote:
> On Sat, Jul 4, 2026 at 11:46 AM Evalyn Goemer <git@xxxxxxxxxxxxxxxx> wrote:
> > On Saturday, July 4, 2026 4:22:40 AM Eastern Daylight Time Christian 
Ludloff wrote:
> > > > https://github.com/InstLatx64/InstLatx64/blob/master/GenuineIotel/Genu
> > > > ineIotel00306C3_Haswell_CPUID5.txt> > 
> > > 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.
> > 
> > parroted around in many places
> 
> 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 
to see if more can be found about it. Along with my friend and maybe others 
checking chips to see if this can be reproduced this could maybe be replicated 
to get other sources properly.

> 
> 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 
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 
a Chinese message board where when expanding the full question it shows a 
"GenuineIotel" on their hardware listing. While it could be a typo it also 
happens to be a haswell series xeon which matches up exactly with other 
reports.

https://web.archive.org/web/20260704102753/https://zhidao.baidu.com/question/
373506097973561924.html

> 
> 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 
handling. I ended up making the patch this way since this is the only case of 
this I could see as well other codebases online handled it similarly. The 
other reason I did it this way was to keep it simpler since it used existing 
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 
quirks table of known bugged vendor strings that resolve to the correct vendor 
and print a log noting that its specifically bugged and assuming the proper one 
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 
you have suggestions on how that should be done.

> 
> --
> 
> Fwiw, I also question the existence of "AMDisbetter!", reported for
> early AMD K5 samples – I have FMS=500h 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 been 
real or just have been something else including things like the "AMD prank 
leaf" being at "0x8FFF_FFFF" according to sandpile.org which has a similar 
issue of not many sources elsewhere.

It would be nice to be able to find more of these CPUs to test them across a 
wide set of boards to see what triggers these and if they can even be 
reproduced at all. Maybe even better find out how these started out being 
spread online.


> 
> --
> C.