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

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

[git]

From: Evalyn Goemer <git@evalyngoemer.com>

Certain Intel CPUs have a bit flipped in the CPUID string causing them
to report as "GenuineIotel" leading to them potentially not being detected
properly as an Intel CPU.

This patch fixes this by adding the "GenuineIotel" string to the
intel_cpu_dev.c_ident array inside the arch/x86/kernel/cpu/intel.c file.

This issue can be found as existing here:
https://github.com/InstLatx64/InstLatx64/blob/master/GenuineIotel/GenuineIotel00306C3_Haswell_CPUID5.txt
https://web.archive.org/web/20150818115122/http://store.steampowered.com/hwsurvey/processormfg

Signed-off-by: Evalyn Goemer <git@evalyngoemer.com>
---
 arch/x86/kernel/cpu/intel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index abb398433..a2dcd6d05 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -713,7 +713,7 @@ static void intel_detect_tlb(struct cpuinfo_x86 *c)
 
 static const struct cpu_dev intel_cpu_dev = {
 	.c_vendor	= "Intel",
-	.c_ident	= { "GenuineIntel" },
+	.c_ident	= { "GenuineIntel", "GenuineIotel" },
 #ifdef CONFIG_X86_32
 	.legacy_models = {
 		{ .family = 4, .model_names =
-- 
2.55.0

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

[Christian Ludloff]

> This issue can be found as existing here:
> https://github.com/InstLatx64/InstLatx64/blob/master/GenuineIotel/GenuineIotel00306C3_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.
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).

Treating GenuineIotel like GenuineIntel is one choice.
Treating GenuineIotel like a rare find is another choice.
Treating GenuineIotel like potentially broken HW seems most logical.

There have been other similar outliers.

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.

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

[David Laight]

On Fri,  3 Jul 2026 22:51:47 -0400
git@evalyngoemer.com wrote:

> From: Evalyn Goemer <git@evalyngoemer.com>
> 
> Certain Intel CPUs have a bit flipped in the CPUID string causing them
> to report as "GenuineIotel" leading to them potentially not being detected
> properly as an Intel CPU.

IIRC that's a BIOS bug.
A lot of that info is written in by the BIOS rather than being in the silicon.

	David

> 
> This patch fixes this by adding the "GenuineIotel" string to the
> intel_cpu_dev.c_ident array inside the arch/x86/kernel/cpu/intel.c file.
> 
> This issue can be found as existing here:
> https://github.com/InstLatx64/InstLatx64/blob/master/GenuineIotel/GenuineIotel00306C3_Haswell_CPUID5.txt
> https://web.archive.org/web/20150818115122/http://store.steampowered.com/hwsurvey/processormfg
> 
> Signed-off-by: Evalyn Goemer <git@evalyngoemer.com>
> ---
>  arch/x86/kernel/cpu/intel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index abb398433..a2dcd6d05 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -713,7 +713,7 @@ static void intel_detect_tlb(struct cpuinfo_x86 *c)
>  
>  static const struct cpu_dev intel_cpu_dev = {
>  	.c_vendor	= "Intel",
> -	.c_ident	= { "GenuineIntel" },
> +	.c_ident	= { "GenuineIntel", "GenuineIotel" },
>  #ifdef CONFIG_X86_32
>  	.legacy_models = {
>  		{ .family = 4, .model_names =

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.

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

[Christian Ludloff]

On Sat, Jul 4, 2026 at 11:46 AM Evalyn Goemer <git@evalyngoemer.com> wrote:
> On Saturday, July 4, 2026 4:22:40 AM Eastern Daylight Time Christian Ludloff wrote:
> > > https://github.com/InstLatx64/InstLatx64/blob/master/GenuineIotel/GenuineIotel00306C3_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.

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.

Overall, it's an outlier, and I'd flag such systems, not placate them.

--

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.  :-)

--
C.

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@evalyngoemer.com> 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.

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

[Borislav Petkov]

On Sat, Jul 04, 2026 at 02:15:02PM -0400, Evalyn Goemer wrote:
> > 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.

Well, Sashiko pointed out a couple more places:

https://sashiko.dev/#/patchset/20260704025147.585133-1-git%40evalyngoemer.com

which would need to be taken care of too.

But I tend to agree with Christian and even go a step further - completely
stop booting on them. Because who knows what else has been tampered with in
them.

Yeah, yeah, bit flips, sure, but a system which generates bit flips reliably
gets its DRAM replaced so why should we treat this thing differently...

Let's see what Intel folks say here too.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

[H. Peter Anvin]

On July 4, 2026 11:29:52 AM PDT, Borislav Petkov <bp@alien8.de> wrote:
>On Sat, Jul 04, 2026 at 02:15:02PM -0400, Evalyn Goemer wrote:
>> > 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.
>
>Well, Sashiko pointed out a couple more places:
>
>https://sashiko.dev/#/patchset/20260704025147.585133-1-git%40evalyngoemer.com
>
>which would need to be taken care of too.
>
>But I tend to agree with Christian and even go a step further - completely
>stop booting on them. Because who knows what else has been tampered with in
>them.
>
>Yeah, yeah, bit flips, sure, but a system which generates bit flips reliably
>gets its DRAM replaced so why should we treat this thing differently...
>
>Let's see what Intel folks say here too.
>

To tell you the truth this is literally the first time I have heard of this at all! 

At the very least we should taint these as CPU_OUT_OF_SPEC. It doesn't seem like a bad idea either to halt *by default*.

I would like to see a command line option to override that behavior, though. Heck, an x86.cpu_vendor=<string> command line option might be useful for debugging in general.

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

[Evalyn Goemer]

On Saturday, July 4, 2026 2:52:14 PM Eastern Daylight Time H. Peter Anvin 
wrote:
> On July 4, 2026 11:29:52 AM PDT, Borislav Petkov <bp@alien8.de> wrote:
> >On Sat, Jul 04, 2026 at 02:15:02PM -0400, Evalyn Goemer wrote:
> >> > 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.>
> >Well, Sashiko pointed out a couple more places:
> >
> >https://sashiko.dev/#/patchset/20260704025147.585133-1-git%40evalyngoemer.c
> >om
> >
> >which would need to be taken care of too.
> >
> >But I tend to agree with Christian and even go a step further - completely
> >stop booting on them. Because who knows what else has been tampered with in
> >them.
> >
> >Yeah, yeah, bit flips, sure, but a system which generates bit flips
> >reliably gets its DRAM replaced so why should we treat this thing
> >differently...
> >
> >Let's see what Intel folks say here too.
> 
> To tell you the truth this is literally the first time I have heard of this
> at all!
> 
> At the very least we should taint these as CPU_OUT_OF_SPEC. It doesn't seem
> like a bad idea either to halt *by default*.
> 
> I would like to see a command line option to override that behavior, though.
> Heck, an x86.cpu_vendor=<string> command line option might be useful for
> debugging in general.

This does seem like a better solution. Would adding a fallback check here in 
arch/x86/kernel/cpu/common.c for the get_cpu_vendor() function before the 
generic error to halt the CPU or if  x86.cpu_vendor.bypass_iotel is set or 
something similar proceed to taint the CPU, log an specific warning but still 
report as an Intel for other code.

If it is by default a halt/panic it may also not need checks in the low level 
code and KVM code mentioned by Sashiko since they are relatively minor and 
needs an explicit bypass to boot on a CPU that is known to be tainted 
regardless.

Do let me know if there is a more proper place for this kind of check but I 
would be glad to make a patch to handle this in such a way since yeah such 
CPUs could have some other worse issues.

What do you think x86.cpu_vendor=<string> should do? My mind is coming up 
blank on this. If this is for emulating specific vendor strings it could be 
done at the hypervisor level for testing.

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

[Christian Ludloff]

On Sat, Jul 4, 2026 at 8:20 PM Evalyn Goemer <git@evalyngoemer.com> wrote:
> > 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

Thanks for digging these up.

Alas, no PPINs back then...

> > 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.

I'd flag the machines as broken.

And then root-cause bad CPU, bad RAM, bad what-not, from there.

> > 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.

I can assure you that the prank leaves listed there are real.  :)

> 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.

The "AMDisbetter!" claims all seem to trace back here:

https://web.archive.org/web/19970524043213/http://grafi.ii.pw.edu.pl/gbm/x86/cpuid.html

My K5 FMS=500h, plus the verbiage used there, makes me say "it's a myth".

--
C.