linux-kernel - Re: [PATCH v2 1/3] KVM: x86: Make the hardcoded APIC bus frequency vm variable

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: <CALMp9eS7DgBkspdPmeB7m7SyWv42V1WEzWQHiyTB3nxtL7JqPQ@mail.gmail.com>
Date: Wed, 20 Dec 2023 14:22:28 -0800
From: Jim Mattson <jmattson@...gle.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Isaku Yamahata <isaku.yamahata@...ux.intel.com>, Maxim Levitsky <mlevitsk@...hat.com>, 
	isaku.yamahata@...el.com, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	isaku.yamahata@...il.com, Paolo Bonzini <pbonzini@...hat.com>, erdemaktas@...gle.com, 
	Vishal Annapurve <vannapurve@...gle.com>
Subject: Re: [PATCH v2 1/3] KVM: x86: Make the hardcoded APIC bus frequency vm variable

On Wed, Dec 20, 2023 at 2:07 PM Sean Christopherson <seanjc@...gle.com> wrote:
>
> On Tue, Dec 19, 2023, Isaku Yamahata wrote:
> > On Mon, Dec 18, 2023 at 07:53:45PM -0800, Jim Mattson <jmattson@...gle.com> wrote:
> > > > There are several options to address this.
> > > > 1. Make the KVM able to configure APIC bus frequency (This patch).
> > > >    Pros: It resembles the existing hardware.  The recent Intel CPUs
> > > >    adapts 25MHz.
> > > >    Cons: Require the VMM to emulate the APIC timer at 25MHz.
> > > > 2. Make the TDX architecture enumerate CPUID 0x15 to configurable
> > > >    frequency or not enumerate it.
> > > >    Pros: Any APIC bus frequency is allowed.
> > > >    Cons: Deviation from the real hardware.
>
> I don't buy this as a valid Con.  TDX is one gigantic deviation from real hardware,
> and since TDX obviously can't guarantee the APIC timer is emulated at the correct
> frequency, there can't possibly be any security benefits.  If this were truly a
> Con that anyone cared about, we would have gotten patches to "fix" KVM a long time
> ago.
>
> If the TDX module wasn't effectively hardware-defined software, i.e. was actually
> able to adapt at the speed of software, then fixing this in TDX would be a complete
> no-brainer.
>
> The KVM uAPI required to play nice is relatively minor, so I'm not totally opposed
> to adding it.  But I totally agree with Jim that forcing KVM to change 13+ years
> of behavior just because someone at Intel decided that 25MHz was a good number is
> ridiculous.
>
> > > > 3. Make the TDX guest kernel use 1GHz when it's running on KVM.
> > > >    Cons: The kernel ignores CPUID leaf 0x15.
> > >
> > > 4. Change CPUID.15H under TDX to report the crystal clock frequency as 1 GHz.
> > > Pro: This has been the virtual APIC frequency for KVM guests for 13 years.
> > > Pro: This requires changing only one hard-coded constant in TDX.
> > >
> > > I see no compelling reason to complicate KVM with support for
> > > configurable APIC frequencies, and I see no advantages to doing so.
> >
> > Because TDX isn't specific to KVM, it should work with other VMM technologies.
> > If we'd like to go for this route, the frequency would be configurable.  What
> > frequency should be acceptable securely is obscure.  25MHz has long history with
> > the real hardware.

I am curious how many other hypervisors either offer a configurable
APIC frequency or happened to also land on 25 MHz.