linux-kernel - Re: [PATCH 0/2] KVM: kvm-coco-queue: Support protected TSC

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: <Zz/DGOoo/mEvULiG@ls.amr.corp.intel.com>
Date: Thu, 21 Nov 2024 15:32:40 -0800
From: Isaku Yamahata <isaku.yamahata@...el.com>
To: "Nikunj A. Dadhania" <nikunj@....com>
Cc: Isaku Yamahata <isaku.yamahata@...el.com>, kvm@...r.kernel.org,
	pbonzini@...hat.com, Sean Christopherson <seanjc@...gle.com>,
	chao.gao@...el.com, rick.p.edgecombe@...el.com,
	yan.y.zhao@...el.com, linux-kernel@...r.kernel.org,
	isaku.yamahata@...il.com, Marcelo Tosatti <mtosatti@...hat.com>,
	Tom Lendacky <thomas.lendacky@....com>,
	isaku.yamahata@...ux.intel.com
Subject: Re: [PATCH 0/2] KVM: kvm-coco-queue: Support protected TSC

On Mon, Oct 14, 2024 at 08:17:19PM +0530,
"Nikunj A. Dadhania" <nikunj@....com> wrote:

> > Solution
> > --------
> > The solution is to keep the KVM TSC offset/multiplier the same as the value of
> > the TDX module somehow.  Possible solutions are as follows.
> > - Skip the logic
> >   Ignore (or don't call related functions) the request to change the TSC
> >   offset/multiplier.
> >   Pros
> >   - Logically clean.  This is similar to the guest_protected case.
> >   Cons
> >   - Needs to identify the call sites.
> > 
> > - Revert the change at the hooks after TSC adjustment
> >   x86 KVM defines the vendor hooks when the TSC offset/multiplier are
> >   changed.  The callback can revert the change.
> >   Pros
> >   - We don't need to care about the logic to change the TSC offset/multiplier.
> >   Cons:
> >   - Hacky to revert the KVM x86 common code logic.
> > 
> > Choose the first one.  With this patch series, SEV-SNP secure TSC can be
> > supported.
> 
> I am not sure how will this help SNP Secure TSC, as the GUEST_TSC_OFFSET and 
> GUEST_TSC_SCALE are only available to the guest.

Although Xiaoyao mentioned KVM emulated timer, let me clarify it.
I think the following is common for SEV-SNP and TDX.

The issue is with guest MSR_IA32_TSC_DEADLINE (and guest local APIC Timer
Initial Count Register).  As long as I understand according to the public
documentation, the SEV-SNP hardware (or the TDX module) doesn't virtualize it so
that the VMM (KVM) has to emulate it.
The KVM uses the host timer(vcpu->arch.apic.lapic_timer) and inject timer
interrupt withit.  KVM tracks TSC multiplier/offset to calculate the host
TSC timeout value based on them.

The KVM multiplier and offset must match with the values the hardware 
(or the TDX module) thinks.  If they don't match,  the KVM tsc deadline timer
(or local APIC timer) emulation is inaccurate.  Timer interrupt is injected
Late or early.

KVM has several points to change tsc multiplier/offset from the original value.
This patch series is to prevent KVM from modifying TSC multipler/offset.

In reality, it's difficult to notice that the timer interrupt is injected late
or early like several miliseconds due to vCPU scheduling.  The injecting timer
interrupt always late harms time sensitive workload (e.g. heart beat) in guest
as Marcelo noticed.

Thanks,
-- 
Isaku Yamahata <isaku.yamahata@...el.com>