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] [day] [month] [year] [list]
Message-ID: <01000198cf7ec03e-dfc78632-42ee-480b-8b51-3446fbb555d1-000000@email.amazonses.com>
Date: Fri, 22 Aug 2025 01:57:27 +0000
From: Colin Percival <cperciva@...snap.com>
To: David Woodhouse <dwmw2@...radead.org>, 
	Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, 
	Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, 
	Vitaly Kuznetsov <vkuznets@...hat.com>, kvm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, graf@...zon.de, 
	Ajay Kaher <ajay.kaher@...adcom.com>, 
	Alexey Makhalov <alexey.makhalov@...adcom.com>
Subject: Re: [PATCH v2 0/3] Support "generic" CPUID timing leaf as KVM guest
 and host

On 8/21/25 14:10, David Woodhouse wrote:
> On Thu, 2025-08-21 at 13:48 -0700, Sean Christopherson wrote:
>>> I think I'm a lot happier with the explicit CPUID leaf exposed by the
>>> hypervisor.
>>
>> Why?  If the hypervisor is ultimately the one defining the state, why does it
>> matter which CPUID leaf its in?
> [...]
> 
> If you tell me that 0x15 is *never* wrong when seen by a KVM guest, and
> that it's OK to extend the hardware CPUID support up to 0x15 even on
> older CPUs and there'll never be any adverse consequences from weird
> assumptions in guest operating systems if we do the latter... well, for
> a start, I won't believe you. And even if I do, I won't think it's
> worth the risk. Just use a hypervisor leaf :)

FreeBSD developer here.  I'm with David on this, we'll consult the 0x15/0x16
CPUID leaves if we don't have anything better, but I'm not going to trust
those nearly as much as the 0x40000010 leaf.

Also, the 0x40000010 leaf provides the lapic frequency, which AFAIK is not
exposed in any other way.

-- 
Colin Percival
FreeBSD Release Engineering Lead & EC2 platform maintainer
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ