Le développeur du jailbreak Dopamine discute du problème insaisissable de Spinlock Timeout Panic

L’ outil de jailbreak Dopamine 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 aujourd’hui d’un choix populaire parmi les jailbreakers .

Mais si vous utilisez Dopamine ou suivez le projet depuis sa création, vous avez probablement entendu un certain mot prononcé à plusieurs reprises par le développeur principal du projet Lars Fröder (@opa334dev) et par 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 membres de la communauté du jailbreak et a depuis été publiée sur une page de problème GitHub pour que le public puisse la 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 lui-même n’est pas le problème, le problème est lié aux pages mémoire . 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 faire une copie spécifique au processus du mappage existant et le mapper par-dessus, de sorte que, par exemple, une page puisse être modifiée en un seul 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.

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 n’ait pas beaucoup de réglages installés pour déclencher le problème, mais je sais qu’il existe de nombreux jailbreakers qui installent des tonnes de réglages de jailbreak – plus que je ne le ferais jamais.

Voir 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.