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 9405E42D753 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=1786054690; cv=none; b=e32szAfxoHrbuzjAVxsrkXkDGmZiP4UdU15FgUGxljr2DzFUTa1zTKSZVHqMOVQq+khXQ6doTc/GkavaiZUjvDmu8mSTSeQO0qzOo7CDKJfl9KYd0htHZx//Um/BKQwbfIG3heq76msn0iLBQE9AqkOO+IHwYsC1XkvJJm3Ievs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786054690; c=relaxed/simple; bh=on3mRg2u5XTVO1NtPed6Wnq5su/1HFfJAZ0A5V6XV54=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=QcHqdX3yOD6wmyg6T/eXqFjli6kfDAuWwY1Ynb5bbf0jFdPRCnqtAyJL82c+PLJevmIuGZb+USo4XorR2RaKfPgoMyxXz6dZIcD5Qqfv6Il8KKyNWicCffM7juGaQrDmTvLdpVvuWB3vLKMf3yUG6YJ3BMbIsdOYinBn9DcMcXM= 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=B/lFDPtt; 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="B/lFDPtt" Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-848d21bbb55so4548311b3a.0 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=lists.linux.dev; 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=B/lFDPttdiaY0+MDQ4JS06lQaMv0Lr1rqFF3OovwQ9jeU236/Kqvxf4OHyiGhbZFFd 4Ad9advojSrrfRi9FtetBy6bj9lHEc26crDKa7lJi+v0yKqK+cl0w6oH5YfNZeyWeC9Z oyLdifYZWivlOEfwWFT0eCeyQL8sMKcEEkA76PdO+VbkYZXobFJlr5BuEmg0cBvZhFpz 25YYdKQDhdlLH9k4GoxqGjX96kXVdhaooUWEAgysolF+EZDtGk6XAZ7c+xTxyGvLtWdQ 1PZXw82LGWXsoT5Xl34YAH9R1CXV+rJT9ueRnO9l+rWP5FbDY3eNTTev12tX5sPZ5Bak /Lpg== 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=nw3AQpPmP9/I/jCatMi1aA5b9A6u5iBmi7/M5UvT4zI2auPQxo/nIVKaELjsEUnIJo QMlAx3xiWLDJq7Nww/7UsQA5SD130+xnx5ApnyWwrpnsJ9vdThv5+3cuh6GtkMWYZQVx 05zuKvKuja9o9WIcakj5DAt6O0/ZUgNGxqcUeYGM+a3WpChNdDsWUlZ7i1a72DmWr34/ 7I0lAZwgKIv6EisHvHvXDI22IhnoQ5dzBfj2zqRz/MSd0tzyE/oF2iDcaIA7rtATbKPl 3dDUdWJbr71K2bYrFYkWT14vXCRFS2/jaLwspLe9ZHNaFnyHrvf/NmuBW3ibmZmdsGBL QqcQ== X-Forwarded-Encrypted: i=1; AHgh+RoijQV7D8a+238gwCskG8YqVakBbhmqeyM1XfxMS7g+ff5C+GwHXsDbUKIi+IPsJ+WF/4vy8LV0lbze@lists.linux.dev X-Gm-Message-State: AOJu0YynQ6tKyG63edkrj4RPNMcekL2coSRyKL6Vq4+3Kd/h78I+Ui3v qEAyR+tp745f+galMKOrQ90R/ZJN00BwP5mevWk/C/6X3ItP3CT60QEnNdB/lbl7ddpZ4+IssbN K3N5k8g== 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-coco@lists.linux.dev 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.