Thema: Manipulation TSC-Register - No-Go?

[mh1962]

Vor einiger Zeit ist mir schon aufgefallen, dass Linux auf eine Veränderung des TSC-Registers sehr "empfindlich" reagiert.

Dieses Register wird ja üblicherweise mit "rdtsc" gelesen, ist aber als MSR realisiert und kann daher auch mit "rdmsr" gelesen und mit "wrmsr" auch geändert werden. Der Index für dieses Register ist 0x10, also kann man bei Linux auf der Kommandozeile sowas wie "wrmsr 0x10 0x..........." machen.

Ich würde ja naiv erwarten, dass sich damit einfach nur die Systemzeit verändert. Tatsächlich passieren aber sehr interessante Dinge, wie ich jetzt ein bisschen systematischer vertestet habe. Es hängt auch ein wenig davon ab, welche "Clocksource" in Linux ausgewählt ist.

Also, ich erhöhe den Wert von TSC und es ist auch tatsächlich "tsc" als Clocksource ausgewählt. Dann springt die System-Zeit tatsächlich in die Zukunft, aber das System verhält sich von da an seltsam, was das Timing angeht - komische Responsezeiten usw. Muss ich noch etwas näher untersuchen.

Bei anderen Clocksources, u.a. bei "xen" in eben einer Xen-VM passiert auch was Interessantes: Das System "friert" für die angegebene Zeit ein (führt auch keine Timer-Interrupts mehr aus) und danach hat es wieder die korrekte Uhrzeit...

Meine Frage: Ist eine Manipulation am TSC-MSR ein generelles No-Go und wenn ja, warum? Oder ist es nur Linux, was empfindlich darauf reagiert? Auch hier: Warum?

[mh1962]

Ach ja, ganz vergessen: Es scheint auch vom Alter des Linux-Kernels abzuhängen, wie ich kurz angetestet habe. Ältere Linux-Kernel haben WENIGER Probleme mit einer TSC-Manipulation... Also doch ein Problem nur in Linux, was vor nicht all zu langer Zeit erst "eingebaut" wurde?

[Svenska]

Ich wollte ja nicht direkt antworten, weil ich davon keine Ahnung habe. Aber dann sieht das Forum so tot aus.

Meine Frage: Ist eine Manipulation am TSC-MSR ein generelles No-Go und wenn ja, warum? Oder ist es nur Linux, was empfindlich darauf reagiert? Auch hier: Warum?

In erster Linie betrifft eine Manipulation am TSC nur Programme, die den TSC auch nutzen.

Mir ist aufgefallen, dass Linux den TSC systemabhängig als "unzuverlässig" deklariert (z.B. wenn er im idle stehen bleibt) und dann in bestimmten Situationen nicht nutzt bzw. neu synchronisiert. Daraus schließe ich einfach mal messerscharf, dass das von dir gesichtete Verhalten auch noch systemabhängig ist.

Was das xen angeht, könnte ich mir durchaus vorstellen, dass du den TSC des Hosts manipulierst und dadurch die VM verwirrst. Dass dann die Uhrzeit stimmt, überrascht mich wiederum nicht - in virtualisierten Systemen ist es unhandlich, die Uhr anhand eines schnell tickenden Timers nachzustellen. Da kann man lieber den Host oder einen anderen Timer (RTC, HPET) fragen.

Dazu kommt noch, dass der TSC zwischen verschiedenen Prozessoren (oder Prozessor-Cores) nicht unbedingt synchronisiert sein muss. Auch das kann zu seltsamen Effekten führen, je nachdem, auf welchem Core der Thread nun gelandet ist. Das wäre ein sehr guter Grund, den TSC innerhalb von Xen nicht zu nutzen.

Es scheint auch vom Alter des Linux-Kernels abzuhängen, wie ich kurz angetestet habe. Ältere Linux-Kernel haben WENIGER Probleme mit einer TSC-Manipulation... Also doch ein Problem nur in Linux, was vor nicht all zu langer Zeit erst "eingebaut" wurde?

Der Kernel läuft auch auf i486 (bis 3.7 auch auf i386), die keinen TSC haben (der kam mit dem Pentium). Würde mich nicht wundern, wenn die Abhängigkeiten diverser Subsysteme auf eine genaue Zeitquelle erst in neuerer Zeit gekommen sind bzw. der Kernel erst in neuerer Zeit den TSC als hinreichend zuverlässig dafür ansieht.

In jedem Fall ist WRMSR laut Wikipedia eine privilegierte Operation. Wenn du also an den Prozessor-Interna rumspielst, dann bist du selbst schuld, wenn danach etwas nicht mehr funktioniert. Ein Sicherheitsproblem ist es jedenfalls nicht, weil du vorher schon alle Rechte hattest.

[mh1962]

Danke für die Antwort!

Bei der Virtualisierung scheint es so zu sein, dass der "Zeitgeber" direkt aus dem Hypervisor kommt, also den "physikalischen" TSC berücksichtigt, während der Zeitpunkt auf den den nächsten Timer-Interrupt aufgrund des "virtualisierten" TSC berechnet wird - und nur den kann ich logischerweise aus der VM heraus verstellen.

Damit wird, wenn ich den TSC "weit" in die Zukunft stelle, der nächste Timer-Interrupt genau für diesen Zeitraum in die Zukunft eingestellt und dazwischen gibt es keine Timer-Interrupts. Folge: Die Rechner-Uhr scheint zu stehen und alle Timer-basierten Operationen, angefangen von einem simplen "sleep", hängen so lange. Daher hängt wohl auch die GUI, da da sicherlich mit Timern gearbeitet wird.

Die "noch seltsameren" Phänomene bei nicht-virtualisierten Systemen habe ich noch nicht verstanden.

Mir geht es auch wirklich nur um's Verständnis. Wenn es ein Register gibt, was ich verstellen kann, dann probiere ich das aus... Nur hier habe ich das Gefühl, dass zumindest Linux versucht, nicht-triviale Verstellungen "auszubremsen", und die Gründe dafür möchte ich eben verstehen.

[Svenska]

Du kannst ja mal das Verhalten anschauen, wenn du den Kernel mit "notsc" bootest.
Eventuell ist dieser Patch hilfreich: http://lkml.iu.edu/hypermail/linux/kernel/1806.2/04234.html

Offensichtlich benutzt der Linux-Scheduler den TSC. Das wiederum lässt vermuten, dass Timer-Interrupts zwar trotzdem feuern (zumindest, wenn es kein TICKLESS-System ist), aber der Scheduler nicht darauf reagiert.