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

[Evalyn Goemer]

On Saturday, July 4, 2026 4:22:40 AM Eastern Daylight Time Christian Ludloff 
wrote:
> > This issue can be found as existing here:
> > https://github.com/InstLatx64/InstLatx64/blob/master/GenuineIotel/GenuineI
> > otel00306C3_Haswell_CPUID5.txt
> > https://web.archive.org/web/20150818115122/http://store.steampowered.com/
> > hwsurvey/processormfg
> To help put this into perspective...
> 
> 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.
I would hope this is not the case since this is seemingly somewhat parroted 
around in many places and seemingly the same string comes up dating back to 
2015.
I have contacted the person behind the InstLatx64 dump to see if they have any 
more info to see if I can help find more information on this specific case and 
maybe see if others have the same thing coming up or can reproduce it.
I also have a friend testing out a bunch of similar chips as well to see if 
the issue can be reproduced on similar hardware.
> It is possible that the reports are the result of bad DRAM memory (RAM).
> It is possible that the reports are the result of bad SRAM memory (CPU).
If it was DRAM/SRAM errors wouldn't they be somewhat less consistent? But yeah 
this is another thing that could be happening. But bad memory would probably 
come with other more severe effects than a single bit in the vendor ID?
I would think it would prevent the dump from working too at least from my 
experiences with bad memory.
> 
> Treating GenuineIotel like GenuineIntel is one choice.
> Treating GenuineIotel like a rare find is another choice.
This may not be the best way to handle it but I'm not sure what would be the 
best. I did the patch this way since this is the only reported thing I was 
able to find for broken CPUID vendor strings for Intel.
> Treating GenuineIotel like potentially broken HW seems most logical.
How should something like this be detected and what actions should be taken 
when this issue is found. Though that should potentially wait until more 
information on this issue can be found and what side effects it comes with.
David Laight in the thread also mentioned it could be a BIOS issue causing 
this which could be some other specific issue that could be detected 
explicitly?
> 
> There have been other similar outliers.
Is there anything that's been seen to be this close on actual genuine chips? 
Nothing like that sadly came up when I was researching this issue.
> 
> In my collection I got a 486 chip (fake-)marked Intel but reporting UMC.
> 
> At the other end of the spectrum, there were CPU models for which the
> microcode patch match registers were not up to spec – as a result they
> exhibited all kinds of undesired behavior, and had to be screened out...
> 
> --
> C.