From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) (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 8E15E42A791 for ; Thu, 6 Aug 2026 22:18:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.200 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786054692; cv=none; b=CUiuIIAYzkfzdN0wsZDnk6fZoo8ls3CnWbC/sXu650c2/ZZAmZ7uDV9kMu6MRQrF7umP1p6SRKp6pE4BTc1bmFkxlUocCBY3oeVK2XxZDLcGN3/sa/O5E5rkpj7o/Ow+8QYs+8wucBf2qFsB4pplhpJv/tPL1TDra4L+vwsC07E= 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.200 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-f200.google.com with SMTP id d2e1a72fcca58-84eccf9d899so3597349b3a.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=c45U24vlm5F8lP6QL0RGYPTFW+4ky/pt7GCvzoUVD/xmjNkt5UFOX8407k9AHJIij8 Y8QEpFpv2gbVXBqRqQalXty83WTCMe9kcZyYbBhC5HvHwb1U3t6PtjjZawJS5DscNqc7 WbAWqAZIDTl+l+BgjiDpBBYLeylXmRg6hCcYHbJK2+d+FVCrV8gd+01i0YD2ibUi1LP8 2RFQHn9Pa+MyQB8dcwzkOsDYZ5dIyOGjyp7reaF67EHZkCuB73RMa78LXWDsQM3ss3au Rtfm9yGddlK1WDHuCp5sHmLLRY1YEYALtu9ek0Em+Q2Kf7LEtzlrUAuys7cmU47oe1y5 NIgA== X-Forwarded-Encrypted: i=1; AHgh+Rr2lc1GSLJJDdp2CcYMHoks6I1+GQ5myAdpV+cXGH0dU/aL6Z9pP6JvN+7Df1rlgk3mo6Ytyq7m8SnVfIM=@vger.kernel.org X-Gm-Message-State: AOJu0YzIulLfoky/vEZ0DS8Na3T1XtlnsMkpcOXY3+Q7VT5/kd5SpGfW Mg4WhL1ZuztNN60/kCv7fO97BhVU9cI7kWR6s2FKaMIKBiQily1vzQjix3ukRuBt97TF2Hhe7q9 yXAoVxQ== 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: linux-kernel@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.