Le développeur du jailbreak Dopamine discute du problème insaisissable de Spinlock Timeout Panic
Le Dopamine L'outil de jailbreak pour les appareils A12-A15 exécutant iOS et iPadOS 15.0-15.4.1 est le dernier jailbreak disponible pour tout appareil plus récent que l'iPhone X à l'heure actuelle. Cela dit, il n’est pas surprenant qu’il s’agisse d’un choix populaire pour jailbreakers aujourd'hui.
Mais si vous utilisez Dopamine ou si vous suivez le projet depuis son lancement, vous avez probablement entendu un certain mot prononcé à plusieurs reprises par le développeur principal du projet, Lars Fröder ( @opa334dev ) et les utilisateurs : Spinlock.
En effet, il existe un problème connu qui affecte le jailbreak Dopamine appelé Spinlock Timeout Panic, et il en résulte finalement que l'appareil d'un utilisateur affiche un écran rose, puis redémarre d'une manière apparemment non provoquée. Le problème a été décrit en termes techniques comme suit :
Le mappage au-dessus des pages exécutables dyld_shared_cache semble déclencher un comportement de cas limite dans le PPL qui provoque parfois un délai d'attente sur le verrou tournant d'une page mémoire, entraînant une panique du noyau.
Plus les fonctions hook C sont installées et plus elles injectent de processus, plus ce comportement semble être déclenché.
Il semble que ce problème pourrait être résolu en câblant toutes les pages qui ont été accrochées, mais l'espace utilisateur ne peut pas prendre un tel verrou et trouver l'objet vm_page dans la mémoire du noyau pour retourner directement le bit câblé s'avère difficile.
Comme je n'ai jamais personnellement rencontré l'un de ces problèmes sur mon appareil Dopamine, il a été difficile d'expliquer à quoi cela ressemble ou quand cela se produit, mais j'ai parlé avec Fröder pour lui demander ce qui, selon eux, pourrait le provoquer. ils tentent d'y remédier.
La réponse de Fröder a été perspicace pour les personnes non techniques comme moi et probablement pour beaucoup d'autres dans la communauté du jailbreak et a depuis été publié sur une page de problème GitHub pour que le public puisse le voir. La réponse complète, citée ci-dessous, révèle la compréhension de Fröder du problème de Spinlock Timeout Panic :
Voici une tentative d'explication plus approfondie du problème, selon ma meilleure compréhension actuelle. Gardez à l’esprit que cela repose sur des hypothèses fondamentalement impossibles à vérifier.
Ainsi, dans un système multithread, des « verrous » sont utilisés pour empêcher deux threads d’interférer l’un avec l’autre. Grâce à cela, un thread peut acquérir un verrou, effectuer la modification et le déverrouiller. Lorsqu'il est verrouillé, un autre thread essayant d'acquérir le verrou attendra que l'objet soit à nouveau déverrouillé.
Un spinlock est essentiellement la même chose, juste utilisé pour des éléments liés aux performances et la principale différence est qu'un spinlock peut expirer si quelque chose prend trop de temps pour le verrou pendant qu'un autre thread tente d'acquérir le verrou. Ainsi, lors de l'acquisition d'un verrou et que l'objet est déjà verrouillé, il attendra quelques ticks et si l'objet n'est pas déverrouillé dans ce laps de temps, il expirera.
Ce mécanisme en soi n'est pas le problème, le problème a à voir avec mémoire pages. Chaque page de mémoire (qui décrit une zone de 16 Ko de RAM) dispose d'un verrou tournant afin qu'il n'y ait aucun problème lorsque plusieurs processus tentent d'acquérir la même page en même temps.
Des pages spécifiques peuvent être mappées dans plusieurs processus (par exemple, si les deux chargent la même bibliothèque), elles réutilisent la même page afin d'économiser de la mémoire. Les ajustements veulent écraser cette mémoire processus par processus, ils doivent donc d'abord créer une copie spécifique au processus du mappage existant et la mapper par-dessus, de sorte que par exemple. une page peut être modifiée dans un processus tout en restant en stock dans les autres processus. Le problème semble se produire spécifiquement lors du mappage en haut d'une page qui réside à l'intérieur du dyld_shared_cache.
Le problème est maintenant qu'Apple n'a probablement jamais testé ce type de hooking et apparemment, lorsque vous le faites dans de nombreux processus, cela peut entraîner la page d'origine (celle du mappage partagé) à être paginée, car elle n'est pas activement utilisée. . La pagination d'une page la supprime essentiellement de la RAM et lorsqu'on y accède à nouveau, elle sera à nouveau chargée. Sur un système de stock, cela n'arrivera pas car rien n'a été accroché.
Maintenant, la cause première semble être quelque chose qui tente de paginer une page partagée/exécutable précédemment paginée, cela déclenche un problème de préemption où un thread prend le spinlock et pendant qu'il l'a, il est préempté vers un contexte différent qui prend également le même spinlock (la préemption est essentiellement un mécanisme qui permet à un thread d'être utilisé pour autre chose même s'il est actuellement occupé, le code doit explicitement le désactiver et le réactiver s'il existe un morceau de code qui doit toujours être exécuté en une seule fois) . Il semble donc y avoir un chemin de code qui n'est invoqué qu'à partir de ce comportement particulier où Apple ne désactive pas correctement la préemption, ce qui conduit un thread à prendre le même spinlock deux fois, ce qui le fait expirer car l'ancien contexte ne s'exécute plus et Je ne peux plus déverrouiller le spinlock.
Pour ce qui est de l'atténuer, j'ai essayé de jouer avec les variables liées au spinlock pour augmenter le seuil nécessaire à son expiration. Malheureusement, Apple nous a foutus car tout ce qui concerne cela est protégé par KTRR, pour lequel nous n'avons pas de contournement. Je suppose que la solution appropriée serait de « câbler » (le câblage d'une page empêche sa pagination) chaque page à accrocher avant qu'elle ne soit écrasée pour garantir que la page ne se produit jamais et donc le chemin de code impliqué dans le le problème ne se déclenche pas, j'ai essayé un tas de choses jusqu'à présent mais il semble qu'il soit carrément impossible d'acquérir un tel câblage à partir de l'espace utilisateur, cela doit donc être fait à l'intérieur du noyau. Malheureusement, les structures impliquées dans ce mappage partagé spécifique à l'origine du problème sont très compliquées et je n'ai pas encore trouvé de moyen d'obtenir le bon objet de page auquel appliquer le câblage.
Le problème Spinlock Timeout Panic existe depuis que la Dopamine est devenue disponible et continue de persister à ce jour. malgré de nombreuses tentatives pour résoudre le problème. Cela dit, ouvrir le dialogue pour qu’un plus grand nombre de personnes puissent le voir et y contribuer est un bon pas en avant, car cela permet à un plus grand nombre d’esprits de réfléchir plus facilement au problème et à une solution possible.
Fröder explique sa prochaine idée pour tenter de contrecarrer le problème dans un commentaire ultérieur :
La prochaine étape pour essayer de résoudre ce problème serait donc de trouver la structure vm_page d'une page DSC dans la mémoire du noyau. Jusqu'à présent, toutes mes tentatives pour trouver une telle structure ont échoué.
Même si cela ne m’a pas encore directement affecté, il sera effectivement intéressant de voir si Fröder est capable de résoudre le problème de Spinlock Timeout Panic. Cela semble être plus répandu chez les utilisateurs qui installent davantage de réglages de jailbreak qui accrochent les fonctions C. Il se peut simplement que mon appareil de test ne dispose pas de nombreux réglages installés pour déclencher le problème, mais je sais qu'il existe de nombreux jailbreakers qui installent des tonnes de ajustements de jailbreak – plus que je ne le ferais jamais.
Regarde aussi: Comment jailbreaker les appareils A12-A15 exécutant iOS et iPadOS 15.0-15.4.1 avec Dopamine
Avez-vous déjà été affecté par une panique Spinlock Timeout décrite comme un écran rose avant un redémarrage soudain lors de l'utilisation du jailbreak Dopamine ? Faites-le nous savoir dans la section commentaires ci-dessous.