linux-kernel - [GIT pull] x86/timers for v6.10-rc1

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: 
 <171560455005.3871325.1102142666677911813.tglx@xen13.tec.linutronix.de>
Date: Mon, 13 May 2024 14:50:02 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org
Subject: [GIT pull] x86/timers for v6.10-rc1

Linus,

please pull the latest x86/timers branch from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-timers-2024-05-13

up to:  455f9075f144: x86/tsc: Trust initial offset in architectural TSC-adjust MSRs

A single update for the TSC synchronixation sanity checks:

  The sad state of TSC being notoriously non-sychronized for several
  decades caused the kernel to grow quite rigorous sanity checks to detect
  whether the TSC is valid to be used for timekeeping.

  The TSC ADJUST MSR provides the offset between the initial TSC value
  after hardware reset and later modifications. This allows to detect cases
  where firmware tampers with the TSC and also allows to correct the
  firmware induced damage by resetting the offset in a controlled way.

  The universal correct rule is that the TSC ADJUST value has to be
  consistent within all CPUs of a socket.

  The kernel further assumes that the TSC offset should be consistent
  between sockets. That's not really correct as systems with a huge number
  of sockets are not architecurally guaranteed to reset the per socket TSC
  base synchronously.

  In case that the per socket offset is not consistent the kernel resets it
  to the offset of the boot CPU and then does a synchronization check which
  corrects for the inter socket delays.

  That works most of the time, but it is suboptimal as the firmware has
  eventually better information about the per socket offset and on sane
  systems that offset should just work in the validation checks.

Thanks,

	tglx

------------------>
Daniel J Blueman (1):
      x86/tsc: Trust initial offset in architectural TSC-adjust MSRs

 arch/x86/kernel/tsc_sync.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/tsc_sync.c b/arch/x86/kernel/tsc_sync.c
index 1123ef3ccf90..4334033658ed 100644
--- a/arch/x86/kernel/tsc_sync.c
+++ b/arch/x86/kernel/tsc_sync.c
@@ -193,11 +193,9 @@ bool tsc_store_and_check_tsc_adjust(bool bootcpu)
 	cur->warned = false;

 	/*
-	 * If a non-zero TSC value for socket 0 may be valid then the default
-	 * adjusted value cannot assumed to be zero either.
+	 * The default adjust value cannot be assumed to be zero on any socket.
 	 */
-	if (tsc_async_resets)
-		cur->adjusted = bootval;
+	cur->adjusted = bootval;

 	/*
 	 * Check whether this CPU is the first in a package to come up. In