From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-139-mta243.mxyeet.net (mail-139-mta243.mxyeet.net [23.172.139.243]) (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 403221AC45D for ; Sat, 4 Jul 2026 19:23:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=23.172.139.243 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783193031; cv=none; b=l8TgVVlLnxLhrLg2DrC+Tqe2gBNpLG8jWN2tVAZGOcV5rOOrbIqXLDfv8DAngj7E4k0G56whhqI3vbM7mNs698sslYlAxCAi3XkH8sKzQ2KpMGM/QhymvJnsjpiY+YnFG57a8jww1RqF05DIo50U52qdGK4CB+cp1ylUoSRt7i4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783193031; c=relaxed/simple; bh=9z4PnOwHu7aYHVWkm0ftCbMnnuluWsaUNsj1LtK0inY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=sTeREQGSOCOE3uX4MNOqN9j6R8bXyjeTFlzcm8YQQ6R6wivRtrPsOrzi/30zF6xiXXbPGfbCpp7fl+HeIO4t00/zuYltt7yrzolAEvKYLps5uyQuEvDGYKOBVR3vREG+wIRA5vWDA3J5IuQxYZBG733z/TUR0T9QzcYf9OClxmc= 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=LAjFujZo; arc=none smtp.client-ip=23.172.139.243 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="LAjFujZo" Received: from us1.workspace.org ([162.244.93.81] us1.workspace.org) (Authenticated sender: smartermail.us1@mxyeet.net) by mail-139-mta243.mxyeet.net (MailFilter Outbound) with ESMTPSA id 19f2e964099000d9a4.009 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 04 Jul 2026 19:23:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=evalyngoemer.com; s=cx8DDCB0BEEEDC8F5; c=relaxed/relaxed; t=1783193026; h=from:to:cc:subject:date:message-id:in-reply-to:references:mime-version; bh=MSIMzTQ+yIZwazq8xrSEijboZOuHNXor33FiAw9TjE4=; b=LAjFujZohxvsSzKszI2RPa+HmJhAoWNRpf2wM8zmknkfI5LqaYwvLJD0QyXJgYDWYBJzAaQMAJD qB22ovOdv+OogP/DLx3ceyEf5V62FfkxQ2nyz0Ojdm7i2eawuB7PTOgvifysm2DL4y5AIR573/uv9 B4pqvtfmc/wtTOwTlJD4pb4MdE8JMEWs1lB8NZZifgMFPmN0lZ2D+ycZwPSNTde0wVIpdls9ogEs8 Uqcdtb4aSsJq33hVtBL0BoVplj+y5szHGIFXExf/UZ7FuifXc2AxwCvz3mgH7GnzwHOp5m/kovLZm wi9wjo8Y0PXoI4vVZ047LSCm4GeNr/WIkxQw== From: Evalyn Goemer To: "H. Peter Anvin" Cc: Borislav Petkov , dave.hansen@linux.intel.com, ludloff@gmail.com, linux-kernel@vger.kernel.org, tglx@kernel.org, mingo@redhat.com, x86@kernel.org, joe@perches.com, Andrew Cooper Subject: Re: [PATCH] platform/x86: handle Intel CPUs falsely reporting as GenuineIotel Date: Sat, 04 Jul 2026 15:23:36 -0400 Message-ID: In-Reply-To: References: <20260704182952.GAaklRINnc6XDFoGcE@fat_crate.local> 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 2:52:14=E2=80=AFPM Eastern Daylight Time H. Peter= Anvin=20 wrote: > On July 4, 2026 11:29:52 AM PDT, Borislav Petkov 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 the= m. > >>=20 > >> 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%40evalyngoeme= r.c > >om > > > >which would need to be taken care of too. > > > >But I tend to agree with Christian and even go a step further - complete= ly > >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. >=20 > To tell you the truth this is literally the first time I have heard of th= is > at all! >=20 > At the very least we should taint these as CPU_OUT_OF_SPEC. It doesn't se= em > like a bad idea either to halt *by default*. >=20 > I would like to see a command line option to override that behavior, thou= gh. > Heck, an x86.cpu_vendor=3D command line option might be useful for > debugging in general. This does seem like a better solution. Would adding a fallback check here i= n=20 arch/x86/kernel/cpu/common.c for the get_cpu_vendor() function before the=20 generic error to halt the CPU or if x86.cpu_vendor.bypass_iotel is set or= =20 something similar proceed to taint the CPU, log an specific warning but sti= ll=20 report as an Intel for other code. If it is by default a halt/panic it may also not need checks in the low lev= el=20 code and KVM code mentioned by Sashiko since they are relatively minor and= =20 needs an explicit bypass to boot on a CPU that is known to be tainted=20 regardless. Do let me know if there is a more proper place for this kind of check but I= =20 would be glad to make a patch to handle this in such a way since yeah such= =20 CPUs could have some other worse issues. What do you think x86.cpu_vendor=3D should do? My mind is coming up= =20 blank on this. If this is for emulating specific vendor strings it could be= =20 done at the hypervisor level for testing.