Dopamin-Jailbreak-Entwickler diskutiert schwer fassbares Spinlock-Timeout-Panic-Problem

Das Dopamin- Jailbreak-Tool für A12-A15-Geräte mit iOS und iPadOS 15.0-15.4.1 ist derzeit der neueste Jailbreak, der für jedes neuere Gerät als das iPhone X verfügbar ist. Dennoch ist es keine Überraschung, dass es heutzutage eine beliebte Wahl für Jailbreaker ist .

Aber wenn Sie Dopamin verwenden oder das Projekt seit seiner Gründung verfolgen, dann haben Sie wahrscheinlich schon oft ein bestimmtes Wort von Projektleiter Lars Fröder (@opa334dev) und Benutzern gleichermaßen gehört: Spinlock.

Tatsächlich gibt es ein bekanntes Problem, das den Dopamin-Jailbreak betrifft und als „Spinlock Timeout Panic“ bezeichnet wird. Dies führt letztendlich dazu, dass das Gerät eines Benutzers einen rosafarbenen Bildschirm anzeigt und dann scheinbar unvorhergesehen neu startet. Das Problem wurde technisch wie folgt beschrieben:

Die Zuordnung über ausführbaren Seiten von dyld_shared_cache scheint ein Randfallverhalten in der PPL auszulösen, das manchmal zu einer Zeitüberschreitung beim Spinlock einer Speicherseite führt, was zu einer Kernel-Panik führt.

Je mehr Optimierungen die Hook-C-Funktionen installiert werden und je mehr Prozesse diese injizieren, desto häufiger scheint dieses Verhalten ausgelöst zu werden.

Es scheint, dass dieses Problem behoben werden könnte, indem alle Seiten, die eingebunden wurden, heruntergefahren werden, aber der Userspace kann eine solche Sperre nicht ertragen und es erweist sich als schwierig, das vm_page-Objekt im Kernel-Speicher zu finden, um das wired-Bit direkt umzudrehen.

Da ich selbst noch nie eines dieser Probleme mit meinem Dopamin-Gerät erlebt habe, war es schwierig zu erklären, wie das aussieht oder wann es auftritt, aber ich habe mit Fröder gesprochen, um zu fragen, was ihrer Meinung nach die Ursache dafür sein könnte, um mehr darüber zu erfahren Sie versuchen, das Problem anzugehen.

Fröders Antwort war für Nicht-Techniker wie mich und wahrscheinlich viele andere in der Jailbreak-Community aufschlussreich und wurde seitdem auf einer GitHub-Problemseite veröffentlicht, damit die Öffentlichkeit sie sehen kann. Die unten zitierte vollständige Antwort zeigt Fröders Verständnis des Spinlock Timeout Panic-Problems:

Hier ist ein Versuch einer ausführlicheren Erklärung des Problems, soweit ich es derzeit nach meinem besten Verständnis verstehe. Bedenken Sie, dass es sich dabei um Annahmen handelt, die grundsätzlich nicht verifizierbar sind.

Daher werden in einem Multithread-System „Sperren“ verwendet, um zu verhindern, dass sich zwei Threads gegenseitig stören. Dadurch kann ein Thread eine Sperre erwerben, die Änderung vornehmen und sie entsperren. Während es gesperrt ist, wartet ein anderer Thread, der versucht, die Sperre zu erlangen, bis das Objekt wieder entsperrt wurde.

Ein Spinlock ist im Wesentlichen dasselbe, wird nur für leistungsrelevante Dinge verwendet und der Hauptunterschied besteht darin, dass ein Spinlock eine Zeitüberschreitung verursachen kann, wenn die Sperre zu lange dauert, während ein anderer Thread versucht, die Sperre zu erlangen. Wenn also eine Sperre erworben wird und das Objekt bereits gesperrt ist, wird ein paar Ticks abgewartet, und wenn das Objekt in diesem Zeitraum nicht entsperrt wird, kommt es zu einer Zeitüberschreitung.

Dieser Mechanismus an sich ist nicht das Problem, das Problem hat mit den Speicherseiten zu tun . Jede Speicherseite (die einen Bereich von 16 KB RAM beschreibt) verfügt über einen Spinlock, sodass es keine Probleme gibt, wenn mehrere Prozesse gleichzeitig versuchen, dieselbe Seite abzurufen.

Bestimmte Seiten können mehreren Prozessen zugeordnet werden (wenn beispielsweise beide dieselbe Bibliothek laden), verwenden sie dieselbe Seite wieder, um Speicher zu sparen. Tweaks möchten diesen Speicher pro Prozess überschreiben, daher müssen sie zunächst eine prozessspezifische Kopie der vorhandenen Zuordnung erstellen und diese darauf abbilden, sodass beispielsweise eine Seite in einem Prozess geändert werden kann, während der Bestand erhalten bleibt in den anderen Prozessen. Das Problem scheint insbesondere dann aufzutreten, wenn die Zuordnung über einer Seite erfolgt, die sich im dyld_shared_cache befindet.

Das Problem besteht nun darin, dass Apple diese Art des Hookings wahrscheinlich nie getestet hat und es offenbar dazu führen kann, dass die ursprüngliche Seite (diejenige der freigegebenen Zuordnung) ausgelagert wird, wenn man sie in vielen Prozessen durchführt, weil sie nicht aktiv verwendet wird . Durch das Auslagern einer Seite wird diese im Wesentlichen aus dem RAM entfernt und bei erneutem Zugriff erneut geladen. Auf einem Aktiensystem wird dies nicht passieren, da nichts eingehakt wurde.

Die Hauptursache scheint nun darin zu liegen, dass versucht wird, eine zuvor ausgelagerte freigegebene/ausführbare Seite wieder einzulagern. Dies löst ein Vorbelegungsproblem aus, bei dem ein Thread den Spinlock übernimmt und, während er diesen hat, in einen anderen Kontext verlagert wird, der ihn ebenfalls übernimmt gleicher Spinlock (Preemption ist im Wesentlichen ein Mechanismus, der es einem Thread ermöglicht, für etwas anderes verwendet zu werden, auch wenn er gerade beschäftigt ist; Code muss ihn explizit deaktivieren und wieder aktivieren, wenn es einen Codeteil gibt, der immer auf einmal ausgeführt werden sollte) . Es scheint also einen Codepfad zu geben, der nur von diesem bestimmten Verhalten aus aufgerufen wird, bei dem Apple die Vorbelegung nicht korrekt deaktiviert, was dazu führt, dass ein Thread zweimal denselben Spinlock verwendet, was zu einer Zeitüberschreitung führt, weil der alte Kontext nicht mehr ausgeführt wird und Der Spinlock lässt sich nicht wieder entsperren.

Das Problem mit der Spinlock-Timeout-Panik besteht seit der ersten Verfügbarkeit von Dopamin und besteht bis heute trotz zahlreicher Versuche, das Problem zu beheben. Dennoch ist es der richtige Schritt nach vorn, den Dialog so zu öffnen, dass mehr Menschen ihn sehen und zu ihm beitragen können, da er es für mehr Köpfe einfacher macht, über das Problem und eine mögliche Lösung nachzudenken.

In einem Folgekommentar erläutert Fröder ihre nächste Idee, dem Problem entgegenzuwirken:

Der nächste Schritt, um das Problem zu beheben, wäre also, die vm_page-Struktur einer DSC-Seite im Kernel-Speicher zu finden. Bisher sind alle meine Versuche, eine solche Struktur zu finden, fehlgeschlagen.

Obwohl es mich noch nicht direkt betroffen hat, wird es in der Tat interessant sein zu sehen, ob Fröder in der Lage ist, das Problem der Spinlock Timeout Panic zu lösen. Es scheint häufiger bei Benutzern vorzukommen, die weitere Jailbreak-Optimierungen installieren, die C-Funktionen einbinden. Es könnte einfach sein, dass auf meinem Testgerät nicht viele Tweaks installiert sind, die das Problem auslösen könnten, aber ich weiß, dass es viele Jailbreaker gibt, die jede Menge Jailbreak-Tweaks installieren – mehr als ich jemals tun würde.

Siehe auch: So jailbreaken Sie A12-A15-Geräte mit iOS und iPadOS 15.0-15.4.1 mit Dopamin

Waren Sie schon einmal von einer Spinlock-Timeout-Panik betroffen, die als rosafarbener Bildschirm vor einem plötzlichen Neustart während der Verwendung des Dopamin-Jailbreaks beschrieben wurde? Lassen Sie es uns im Kommentarbereich unten wissen.