On Fri, 2026-05-15 at 12:19 -0700, Sean Christopherson wrote: > 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. > > Signed-off-by: Sean Christopherson <[email protected]>
And kvmclock. And Xen. Are there *any* reasons we'd use a PV sched_clock when the TSC is usable? Reviewed-by: David Woodhouse <[email protected]> > --- > 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 3c15fc10e501..ac4abfec1f05 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; > + > if (!stable) > clear_sched_clock_stable(); >
smime.p7s
Description: S/MIME cryptographic signature
