linux-kernel - Re: [PATCH v16 12/13] x86/tsc: Switch to native sched clock

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: <20250108153420.GEZ36a_IqnzlHpmh6K@fat_crate.local>
Date: Wed, 8 Jan 2025 16:34:20 +0100
From: Borislav Petkov <bp@...en8.de>
To: Sean Christopherson <seanjc@...gle.com>
Cc: "Nikunj A. Dadhania" <nikunj@....com>, linux-kernel@...r.kernel.org,
	thomas.lendacky@....com, x86@...nel.org, kvm@...r.kernel.org,
	mingo@...hat.com, tglx@...utronix.de, dave.hansen@...ux.intel.com,
	pgonda@...gle.com, pbonzini@...hat.com, francescolavra.fl@...il.com,
	Alexey Makhalov <alexey.makhalov@...adcom.com>,
	Juergen Gross <jgross@...e.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [PATCH v16 12/13] x86/tsc: Switch to native sched clock

On Wed, Jan 08, 2025 at 06:00:59AM -0800, Sean Christopherson wrote:
> This still misses my point. 

Oh I got it, no worries.

> Ditto for the "x86/tsc: Switch Secure TSC guests away from kvm-clock".
> 
> I object to singling out kvmclock.  It's weird and misleading, because handling
> only kvmclock suggests that other PV clocks are somehow trusted/ok, when in
> reality the only reason kvmclock is getting singled out is (presumably) because
> it's what Nikunj and the other folks enabling KVM SNP test on.

Presumably.

> What I care most about is having a sane, consistent policy throughout the kernel.
> E.g. so that a user/reader walks away with an understanding PV clocks are a
> theoretical host attack vector and so should be avoided when Secure TSC is
> available.

Yap, agreed.

> Ideally, if the TSC is the preferred clocksource, then the scheduler will use the
> TSC and not a PV clock irrespective of STSC.  But I 100% agree with Boris that
> it needs buy-in from other maintainers (including Paolo), because it's entirely
> possible (likely, even) that there's an angle to scheduling I'm not considering.

That's exactly why I wanted to have this taken care of only for the STSC side
of things now and temporarily. So that we can finally land those STSC patches
- they've been pending for waaay too long.

And then ask Nikunj nicely to clean up this whole pv clock gunk, potentially
kill some of those old clocksources which probably don't matter anymore.

But your call how/when you wanna do this.

If you want the cleanup first, I'll take only a subset of the STSC set so that
I can unload some of that set upstream.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette