Wie testet man den Kernel auf Kernel Panics?

Es gibt eine Vielzahl von Tools, die Sie verwenden können, um Ihren Computer zum Absturz zu bringen:

crashme versucht, zufälligen Code auszuführen; Dies ist gut zum Testen des Lebenszykluscodes des Prozesses.

fsx ist ein Werkzeug, um zu versuchen, den Dateisystemcode ausgiebig auszuüben; es ist gut zum Testen von Treibern, Block-io und Dateisystemcode.

Das Linux-Testprojekt zielt darauf ab, ein großes Repository von Kernel-Testfällen zu erstellen. Es ist möglicherweise nicht speziell mit abstürzenden Systemen ausgelegt, aber es kann viel dazu beitragen, dass Sie und Ihr Team alles so halten, wie es geplant ist. (Beachten Sie, dass das LTP nicht proskriptiv ist - die Kernel-Gemeinschaft behandelt ihre Tests nicht als etwas Wichtiges - aber das LTP-Team versucht sehr, deskriptiv zu sein was der Kernel tut und was nicht.)

Wenn Ihr Gerät mit dem Netzwerk verbunden ist, können Sie nmap mit einer Vielzahl von Scanoptionen ausführen: -sV --version-all versucht dies finde Versionen aller laufenden Dienste (dies kann stressig sein), -O --osscan-guess wird versuchen, das Betriebssystem zu bestimmen, indem man seltsame Netzwerkpakete auf die Maschine wirft und nach Antworten rät, was die Ausgabe ist.

Das nessus Scan-Tool übernimmt auch die Versionsidentifizierung laufender Services; Es kann aber auch Verbesserungen gegenüber nmap bieten oder auch nicht.

Sie können Ihr Gerät auch an Benutzer weitergeben. Sie finden die verrücktesten Dinge, die mit Software zu tun haben, sie werden Fehler entdecken, die Sie nie für nötig halten würden. :)

Sie können die folgende Tastenkombination versuchen

SysRq + c

oder

  

echo c & gt; / proc / sysrq-trigger

Es ist bekannt, dass Crashme unbekannte Kernel-Panic-Situationen findet, aber es muss auf eine potente Art und Weise ausgeführt werden, die eine Vielzahl von Signalausnahmen erzeugt, die innerhalb des Prozesses und einer Vielzahl von Prozessausstiegsbedingungen behandelt werden.

Der Hauptzweck der von Crashme erzeugten Nachrichten besteht darin, festzustellen, ob genügend interessante Dinge passieren, um eine mögliche Potenz anzuzeigen. Wenn beispielsweise der Aufruf mprotect benötigt wird, um Speicher mit malloc als Anweisungen auszuführen, und wenn Sie% cr_de% im Quelltext crashme.c für Ihre Plattform nicht aktiviert haben, dann Crashme ist impotent.

Es scheint, dass Betriebssysteme auf x64-Architekturen dazu neigen, die Ausführung von Datensegmenten zu deaktivieren. Kürzlich habe ich die crashme.c auf Ссылка aktualisiert, um mprotect im Falle von mprotect zu verwenden und getestet auf einem laufenden MacBook Pro MAC OS X Löwe. Dies ist das erste ernsthafte Update für Crashme seit 1994. Rechne damit, bald Centos und Freebsd zu sehen.