linux-kernel - Re: [PATCH AUTOSEL 5.10 2/6] x86/cpu: Don't clear X86_FEATURE_LAHF_LM flag in init_amd_k8() on AMD when running in a virtual machine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250418173643.GEaAKNq_1Nq9PAYf4_@fat_crate.local>
Date: Fri, 18 Apr 2025 19:36:43 +0200
From: Borislav Petkov <bp@...en8.de>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Pavel Machek <pavel@...x.de>, Sasha Levin <sashal@...nel.org>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	Max Grobecker <max@...becker.info>, Ingo Molnar <mingo@...nel.org>,
	tglx@...utronix.de, mingo@...hat.com, dave.hansen@...ux.intel.com,
	x86@...nel.org, thomas.lendacky@....com, perry.yuan@....com,
	mario.limonciello@....com, riel@...riel.com, mjguzik@...il.com,
	darwi@...utronix.de
Subject: Re: [PATCH AUTOSEL 5.10 2/6] x86/cpu: Don't clear
 X86_FEATURE_LAHF_LM flag in init_amd_k8() on AMD when running in a virtual
 machine

On Fri, Apr 18, 2025 at 10:19:14AM -0700, Sean Christopherson wrote:
> Uh, and the hypervisor too?  Why is the hypervisor enumerating an old K8 CPU for
> what appears to be a modern workload?
> 
> > I'd say this is not good stable candidate.
> 
> Eh, practically speaking, there's no chance of this causing problems.  The setup
> is all kinds of weird, but AIUI, K8 CPUs don't support virtualization so there's
> no chance that the underlying CPU is actually affected by the K8 bug, because the
> underlying CPU can't be K8.  And no bare metal CPU will ever set the HYPERVISOR
> bit, so there won't be false positives on that front.
> 
> I personally object to the patch itself; it's not the kernel's responsibility to
> deal with a misconfigured VM.  But unless we revert the commit, I don't see any
> reason to withhold this from stable@.

I objected back then but it is some obscure VM migration madness (pasting the
whole reply here because it didn't land on any ML):

Date: Tue,  17 Dec 2024 21:32:21 +0100
From: Max Grobecker <max@...becker.info>
To: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Max Grobecker <max@...becker.info>, x86@...nel.org
Subject: Re: [PATCH v2] Don't clear X86_FEATURE_LAHF_LM flag in init_amd_k8()
 on AMD when running in a virtual machine
Message-ID: <d77caeea-b922-4bf5-8349-4b5acab4d2eb>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=utf-8

Hi,

sorry for my late response, was hit by a flu last days.

On Tue, 10 Dec 2024 13:51:50 +0100, Borislav Petkov wrote:
> Lemme get this straight: you - I don't know who "we" is - are running K8
> models in guests? Why?

Oh, I see, I missed to explain that, indeed.

This error happens, when I start a virtual machine using libvirt/QEMU while 
not passing through the host CPU. I do this, because I want to be 
able to live-migrate the VM between hosts, that have slightly different CPUs.
Migration works, but only if I choose the generic "kvm64" CPU preset to be
used with QEMU using the "-cpu kvm64" parameter:

  qemu-system-x86_64 -cpu kvm64

I also explicitly enabled additional features like SSE4.1 or AXV2 to have as
most features as I can but still being able to do live-migration between hosts.

By using this config, the CPU is identified as "Common KVM processor"
inside the VM:

  processor       : 0
  vendor_id       : AuthenticAMD
  cpu family      : 15
  model           : 6
  model name      : Common KVM processor

Also, the model reads as 0x06, which is set by that kvm64 CPU preset,
but usually does not pose a problem.

The original vendor id of the host CPU is still visible to the guest, and in
case the host uses an AMD CPU the combination of "AuthenticAMD" and model 0x06
triggers the bug and the lahf_lm flag vanishes.
If the guest is running with the same settings on an Intel CPU and therefore 
reads "GenuineIntel" as the vendor string, the model is still 0x06, but also 
the lahf_lm flag is still listed in /proc/cpuinfo.

The CPU is mistakenly identified to be an AMD K8 model, while, in fact, nearly
all features a modern Epyc or Xeon CPU is offering, are available.

Greetings,
 Max

-- 
Regards/Gruss,
    Boris.

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