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: <5cf35021-c81f-43e3-9d0d-69604fc4fa59@intel.com>
Date: Thu, 21 Dec 2023 13:44:05 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Sean Christopherson <seanjc@...gle.com>,
 Isaku Yamahata <isaku.yamahata@...ux.intel.com>
Cc: Jim Mattson <jmattson@...gle.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 12/21/2023 6:07 AM, Sean Christopherson 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.

I believe 25MHz was chosen because it's the value from hardware that 
supports TDX and it is not going to change for the following known 
generations that support TDX.

It's mainly the core crystal frequency. Yes, it also represents the APIC 
frequency when it's enumerated in CPUID 0x15. However, it also relates 
other things, like intel-pt MTC Freq. If it is configured to other value 
different from hardware, I think it will break the correctness of 
INTEL-PT MTC packets in TDs.

>>>> 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.
>