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

[Evalyn Goemer <git@evalyngoemer.com>]

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.