From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 61F0242CB03 for ; Thu, 6 Aug 2026 22:18:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.198 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786054692; cv=none; b=fQtLmrkupsQO4ouVpszOkp1j6nB2nCwS0FDL3ZcMW8cUIy+chNOK/CwQSOOVYpIPig/6TmWcLbEeEpWIpyG+W+tjHgi9VSIdpSbPVEFSlp+TkAw5hG43GqkhAJCLsNEDGQpNFpfHlkVCp2IciIR2RaOh0lQC+shG3ojivWRRjiU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786054692; c=relaxed/simple; bh=on3mRg2u5XTVO1NtPed6Wnq5su/1HFfJAZ0A5V6XV54=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=ljSIarqYqMFswvOi71iQ+a9w+qmPoydCVgFq9a+AQUeuseHyapF3RsxnFLRr4vYQ32jHyMEFSHxBgdlHTSlER0nqiyrkzjxUx/MkVPhaiVCTuQiu6/tjRNhMql19ySRFLSrMtyLKdctTHm3dhbbNVRBjACQzi/hGQcAkoztDUWc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=c0zyvnWr; arc=none smtp.client-ip=209.85.210.198 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="c0zyvnWr" Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-84eccf9d899so3597351b3a.2 for ; Thu, 06 Aug 2026 15:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786054686; x=1786659486; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=/BEVvi4/7i6XDSu/QYDIwcuZoEPs9pbAb29S0DeOBes=; b=c0zyvnWrdAFI8VFr+T7yfPo4tTie0zkMyU5vE9IpFpQ0bnMIrYNe7D0NVU015/CXq7 tTbpg+GiP1jxYehCF2k+ss1WmL9zCZkVS/XP0JucnBtnbFrZkun5/zwtPKeVvswIcv0x 9OXKkSojC+SITbl2r6dWFilo0SBjtSgUXGY7YnzSHnPU836SD7nqqW9ITYT/jJd2JfJs YEHVrb3r0enPzU2kmPfGXFNmXi/PHHzpE2fxx1rujcOQQ7gqf5oljFESaE7Lq4tlkZTn WgYMlIoEKzbDMturQFbG5GZceqZ9xgZGT0PW3z3gR7B9CbY4okSoPvvfuMih1H9+/ciy UOxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786054686; x=1786659486; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=/BEVvi4/7i6XDSu/QYDIwcuZoEPs9pbAb29S0DeOBes=; b=PKpO0X2ygKSawR6Va3OnQVeetgCsb2f+OkXrqR69qywrIMdlSBp9QfxYp8gguLgwuI CUzKJatVogDhC3RWlJAcIvM6aca5K8nzG57dkSRXgMMHtdevkWDqtdiracfdej9FEFjW JfVEGDYyYjUYybsGXzIZOBE7bL4wHqvbEsGFbo5D2XwD9T3dQTg7j+5BJfe6bUFIBXbo gwRnZ/+/lnp+fm9KNuAarH49aOPgeI/0L1k9u1AQVKt2SG1IhXcEX/pG33oFJtjI7/4M ZEtlQft0pvDPDsOSFi0NDXWdXcoYWjGhSMFuvzEmUVCPV0QaW+IV6RskiHPr/4nDnW4b jaeQ== X-Forwarded-Encrypted: i=1; AHgh+RondItiFzf8TG1M1SQHj+poR6g7uDuU+9/W6MHTftZSKD8i7WumIWQAh0JPkFIXhHIqvWk=@vger.kernel.org X-Gm-Message-State: AOJu0Yzx4rmkpkKu7riQ5wco4zeUq8MUraffT7lArC3Wb35LeYZRiuOI uodbQ0A481tTiNEVUlvygVdV+ypgHdO88VpsGmIykUCsjjwZFur8hYyNh0fJtdPkstnykF/D2h6 4iLqylw== X-Received: from pfbln15.prod.google.com ([2002:a05:6a00:3ccf:b0:848:5415:1869]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3a0f:b0:848:3f07:c5a2 with SMTP id d2e1a72fcca58-84f2dfd0a06mr18297213b3a.4.1786054685697; Thu, 06 Aug 2026 15:18:05 -0700 (PDT) Date: Thu, 6 Aug 2026 15:18:05 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260701193212.749551-1-seanjc@google.com> <20260701193212.749551-48-seanjc@google.com> Message-ID: Subject: Re: [PATCH v5 47/51] x86/paravirt: Don't use a PV sched_clock in CoCo guests with trusted TSC From: Sean Christopherson To: Michael Kelley Cc: Jonathan Corbet , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "x86@kernel.org" , Kiryl Shutsemau , Rick Edgecombe , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Ajay Kaher , Alexey Makhalov , Jan Kiszka , Andy Lutomirski , Peter Zijlstra , Juergen Gross , Daniel Lezcano , John Stultz , Shuah Khan , "H. Peter Anvin" , Vitaly Kuznetsov , Broadcom internal kernel review list , Boris Ostrovsky , Stephen Boyd , "linux-doc@vger.kernel.org" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-coco@lists.linux.dev" , "linux-hyperv@vger.kernel.org" , "virtualization@lists.linux.dev" , "xen-devel@lists.xenproject.org" , Tom Lendacky , Nikunj A Dadhania , David Woodhouse , David Woodhouse , Thomas Gleixner Content-Type: text/plain; charset="us-ascii" On Thu, Jul 02, 2026, Michael Kelley wrote: > From: Sean Christopherson Sent: Wednesday, July 1, 2026 12:32 PM > > > > Silently ignore attempts to switch to a paravirt sched_clock when running > > as a CoCo guest with trusted TSC. In hand-wavy theory, a misbehaving > > hypervisor could attack the guest by manipulating the PV clock to affect > > guest scheduling in some weird and/or predictable way. More importantly, > > reading TSC on such platforms is faster than any PV clock, and sched_clock > > is all about speed. > > > > Reviewed-by: David Woodhouse > > Signed-off-by: Sean Christopherson > > --- > > arch/x86/kernel/tsc.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c > > index 012321fed5e5..a146fc7b5e74 100644 > > --- a/arch/x86/kernel/tsc.c > > +++ b/arch/x86/kernel/tsc.c > > @@ -283,6 +283,15 @@ bool using_native_sched_clock(void) > > int __init __paravirt_set_sched_clock(u64 (*func)(void), bool stable, > > void (*save)(void), void (*restore)(void)) > > { > > + /* > > + * Don't replace TSC with a PV clock when running as a CoCo guest and > > + * the TSC is secure/trusted; PV clocks are emulated by the hypervisor, > > + * which isn't in the guest's TCB. > > + */ > > + if (cc_platform_has(CC_ATTR_GUEST_SNP_SECURE_TSC) || > > + boot_cpu_has(X86_FEATURE_TDX_GUEST)) > > + return -EPERM; > > Do a pr_warn() in the error case? Your commit message says to do the ignore > silently, but I wonder if that's a good idea. At least for Hyper-V, the error > case shouldn't happen. I agree it's not a great idea, but unfortunately it's pretty much guaranteed to fire on KVM-based setups. The KVM world hasn't been anywhere near as aggressive as Hyper-V in terms of killing off PV features when running SNP/TDX guests (which is largely how this series came to be in the first place). So while I'm conceptually not opposed to the idea of printing an error message, in practice I'm pretty strong against it because odds are very good I'll end up dealing with "bug" reports due to less-than-awesome setups.