Nachrichten

1

Lowlevel-Coding / Antw:Herausfinden, ob ein MSR implementiert ist

« am: 19. June 2019, 06:44 »

Genauso habe ich jetzt auch mein konkretes Problem gelöst. War der Weg des geringsten Widerstands.

Die allgemeine Lösung gefällt mir grundsätzlich besser und es müsste auch grundsätzlich mit einem Exception Handler funktionieren.

In grub scheinen keine Exception Handler aktiv zu sein, deswegen scheint ein Zugriff auf einen nicht existierenden MSR einen Triple-Fault und somit einen Reboot auszulösen.

Interessanterweise habe ich festgestellt, dass grub im "git head" seit März die Kommandos "rdmsr" und "wrmsr" auf der grub-Kommandozeilen-Ebene implementiert. Allerdings auch ohne Exception-Handler, statt sogar als "todo" in der Source drin...

Dennoch, wenn ich mal Zeit und Lust hab, versuche ich mal einen Exception-Handler für innerhalb grub zu implementieren...

Übrigens, der Linux-Kernel implementiert folgende Lösung, die ich aber noch nicht wirklich verstanden habe:

https://github.com/torvalds/linux/blob/afe6fe7036c6efdcb46cabc64bec9b6e4a005210/arch/x86/include/asm/msr.h#L137

2

Lowlevel-Coding / Antw:Herausfinden, ob ein MSR implementiert ist

« am: 17. June 2019, 16:50 »

Hm, ein heute durchgeführter Test scheint doch zu belegen, dass ein rdsmr mit ungültigem MSR eine Exception auslöst.

Fragt sich nur, wie ich das - konkreter heutiger Fall - in einem grub-Module am besten handhabe, denn grub2 scheint von sich aus keine Exception-Handler zu unterstützen...

3

Lowlevel-Coding / Herausfinden, ob ein MSR implementiert ist

« am: 17. June 2019, 08:54 »

Ich bin jetzt schon zum zweiten Mal über die Frage gestolpert: Wie kann ich eigentlich herausfinden, ob ein bestimmter (beliebiger) MSR auf einem vorliegenden Prozessor implementiert ist?

Beim ersten Mal dachte ich, mach halt "rdmsr" und implementiere einen Exception-Handler. Ich hatte damals aber den Eindruck, dass ein nicht existierender MSR keine Exception auslöst (wobei ich nicht ausschließen will, dass ich damals da was falsch codiert habe und der Eindruck falsch ist). Da ich das damalige Problem dann irgendwie ganz anders gelöst habe, bin ich der Sache dann aber doch nicht weiter nachgegangen.

Jetzt stehe ich wieder vor derselben Frage.

Was ist also der richtige Weg?

4

Softwareentwicklung / Antw:Re: GRUB4DOS funktioniert nicht

« am: 25. April 2019, 12:59 »

Alle COM-Dateien, und damit auch bootlace.com, sind 16-Bit DOS-Programme (die gehen auf CP/M und die 70er zurück). Ein 64-bittiges Windows unterstützt diese nicht mehr.

Dies ist glaube ich in der Generalität nicht richtig:

Code: [Auswählen]

$ file `which mode.com`
/c/Windows/system32/mode.com: PE32 executable for MS Windows (console) Intel 80386 32-bit


5

Lowlevel-Coding / Antw:Manipulation TSC-Register - No-Go?

« am: 26. March 2019, 04:44 »

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.

6

Lowlevel-Coding / Antw:Manipulation TSC-Register - No-Go?

« am: 19. March 2019, 04:54 »

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?

7

Lowlevel-Coding / Manipulation TSC-Register - No-Go?

« am: 19. March 2019, 04:34 »

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?

8

Offtopic / Antw:Vorstellung

« am: 14. March 2019, 14:00 »

Nein, eigene Treiber bringt mein Hypervisor nicht mit, ich erlaube Linux einfach den Zugriff auf die Hardware.

Linux bootet komplett durch, ich kann mich auf der Console einloggen.

Ich habe Intercepts für die Dinge implementiert, die die (in Bochs simulierte) CPU anbietet, also z.B. in- und out-Statements, Interrupts, cpuid, rdmsr, wrmsr. Eine kleine (Compile-Time-)"Plugin"-Schnittstelle habe ich auch schon implementiert, ebenso einen Host-Daemon, der mit dem Hypervisor kommunizieren kann (der kann noch nicht viel, aber die Schnittstellen wären da...).

Was nicht geht ist DMA, leider implementiert Bochs keine virtuelle IOMMU, somit kann man leider dort keinen "generischen" DMA-Support implementieren.

Und auch insgesamt ist der Hypervisor bewusst sehr einfach gehalten, unterstützt nur eine CPU (Host wie VM), nur eine VM und die (derzeit) mit fester Memory-Größe, um einigen Problemen von vornherein aus dem Weg zu gehen...

Die Lerneffekte waren trotzdem sehr interessant...

9

Lowlevel-Coding / Antw:Bochs-Timing

« am: 14. March 2019, 13:46 »

Danke für die Antwort. Mit "clock" hatte ich auch schon mal getestet, aber komischerweise scheinen (zumindest bei mir) die dort gemachten Einstellungen nichts (sichtbares) zu bewirken, ich hab's grade noch mal probiert...

10

Lowlevel-Coding / Bochs-Timing

« am: 11. March 2019, 15:48 »

Als Test-Plattform für meinen Hypervisor habe ich Bochs samt Debugger durchaus schätzen gelernt.

Mit einer Sache komme ich aber bei Bochs nicht zurecht und ich finde auch beim Googlen nicht wirklich die Antwort darauf: Das Timing.

Wenn ein System unter Bochs erst mal fertig gebootet hat und "idle" ist, scheint die Zeit in Bochs zu "rasen". Das macht es auch schwierig, sich da einzuloggen, da das Login schneller auf Timeout läuft als ich tippen kann...

Wenn ich in der bochsrc den Wert für ips bei cpu erhöhe, ist es nicht ganz so schlimm - aber dann wird das Booten in Bochs "noch langsamer" als es ohnehin schon ist. Im Moment benutze ich einen empirisch ermittelten Wert, wo beides sich im erträglichen Bereich befindet, aber so richtig zufrieden bin ich nicht.

Sicher mache ich nur einen dummen Fehler und habe irgendwas noch nicht richtig verstanden. Nur was?

Für Tiipps wäre ich sehr dankbar!

11

Offtopic / Vorstellung

« am: 11. March 2019, 15:41 »

Hallo!

Erst mal vielen Dank für die Freischaltung meines Accounts.

Mein Name ist Manfred. Ich beschäftige mich zwar schon lange mit Betriebssystemen und Hypervisoren, wenn auch mehr als Admin (und Benutzer), bin aber seit einiger Zeit dabei, mich fleißig mit den Grundlagen zu beschäftigen.

Zum "Üben" habe ich in den letzten Wochen mal einen einfachen Hypervisor für den x86_64 geschrieben, der zumindest schon mal ein Linux als Client anbooten kann. Veröffentlichungsreif ist der nicht wirklich, aber ich habe eine Menge dabei gelernt, was ich vielleicht mal in anderen Projekten gebrauchen kann.

Da ja hier viele Leute mit ähnlichen Interessen und sicherlich einem größeren Wissen als bei mir versammelt sind, denke ich, dass ich die eine oder andere Frage hier mal los werden kann...