El desarrollador de Dopamine jailbreak analiza el elusivo problema de Spinlock Timeout Panic

La herramienta de jailbreak Dopamine para dispositivos A12-A15 que ejecutan iOS y iPadOS 15.0-15.4.1 es el último jailbreak disponible para cualquier dispositivo más nuevo que el iPhone X en este momento. Dicho esto, no sorprende que sea una opción popular entre los jailbreakers de hoy.

Pero si ha estado usando Dopamine o ha seguido el proyecto desde su inicio, entonces probablemente haya escuchado cierta palabra varias veces por parte del desarrollador líder del proyecto Lars Fröder (@opa334dev) y de usuarios por igual: Spinlock.

De hecho, existe un problema conocido que afecta el jailbreak de Dopamine llamado Spinlock Timeout Panic y, en última instancia, hace que el dispositivo del usuario muestre una pantalla rosa y luego se reinicie de una manera aparentemente no provocada. El problema se ha descrito en términos técnicos de la siguiente manera:

El mapeo sobre las páginas ejecutables de dyld_shared_cache parece desencadenar un comportamiento extremo en el PPL que a veces causa un tiempo de espera en el bloqueo de giro de una página de memoria, lo que resulta en un pánico en el kernel.

Cuantos más ajustes se instalan en las funciones de C y en más procesos se inyectan, más a menudo parece desencadenarse este comportamiento.

Parece que este problema podría solucionarse conectando todas las páginas que se han enganchado, pero el espacio de usuario no puede aceptar dicho bloqueo y encontrar el objeto vm_page en la memoria del kernel para voltear el bit cableado directamente está resultando difícil.

Como nunca he experimentado personalmente uno de estos problemas en mi dispositivo de dopamina, ha sido difícil explicar cómo se ve o cuándo sucede, pero hablé con Fröder para preguntarle qué creen que podría estar causando esto para aprender más sobre cómo. están intentando abordarlo.

La respuesta de Fröder fue reveladora para personas sin conocimientos técnicos como yo y probablemente para muchos otros en la comunidad de jailbreak y desde entonces se publicó en una página de edición de GitHub para que la vea el público. La respuesta completa, citada a continuación, revela la comprensión de Fröder sobre el problema del Spinlock Timeout Panic:

Aquí hay un intento de explicar más en profundidad el tema, según mi mejor comprensión actual del mismo. Tenga en cuenta que se basa en suposiciones que son básicamente imposibles de verificar.

Entonces, en un sistema de subprocesos múltiples, se utilizan «bloqueos» para evitar que dos subprocesos interfieran entre sí. Mediante ese hilo puede adquirir un bloqueo, realizar la modificación y desbloquearlo. Mientras está bloqueado, otro hilo que intente adquirir el bloqueo esperará hasta que el objeto se haya desbloqueado nuevamente.

Un spinlock es esencialmente lo mismo, solo se usa para cosas relevantes para el rendimiento y la principal diferencia es que un spinlock puede expirar si algo demora demasiado el bloqueo mientras otro subproceso intenta adquirir el bloqueo. Entonces, al adquirir un bloqueo y el objeto ya está bloqueado, esperará algunos tics y si el objeto no se desbloquea en ese período de tiempo, expirará.

Este mecanismo por sí solo no es el problema, el problema tiene que ver con las páginas de memoria . Cada página de memoria (que describe un área de 16 kB de RAM) tiene un bloqueo de giro para que no haya problemas cuando varios procesos intentan adquirir la misma página al mismo tiempo.

Las páginas específicas se pueden asignar a múltiples procesos (por ejemplo, si ambos cargan la misma biblioteca), reutilizan la misma página para ahorrar memoria. Los ajustes quieren sobrescribir dicha memoria por proceso, por lo que primero deben hacer una copia específica del proceso de la asignación existente y asignarla encima de ella, de modo que, por ejemplo, se pueda modificar una página en un proceso mientras se mantiene el stock. en los demás procesos. El problema parece ocurrir específicamente cuando se mapea en la parte superior de una página que reside dentro de dyld_shared_cache.

El problema ahora es que Apple probablemente nunca probó este tipo de enganche y aparentemente cuando lo haces en muchos procesos, puede causar que la página original (la del mapeo compartido) se elimine porque no se está utilizando activamente. . Al paginar una página esencialmente se elimina de la RAM y cuando se accede nuevamente a ella se cargará nuevamente. En un sistema de acciones esto no sucederá porque no se ha enganchado nada.

Ahora la causa raíz parece ser algo que intenta volver a ingresar a una página compartida/ejecutable previamente paginada, esto desencadena un problema de preferencia en el que un subproceso toma el bloqueo de giro y, mientras lo tiene, se adelanta a un contexto diferente que también toma el mismo spinlock (la preferencia es esencialmente un mecanismo que permite que un hilo se use para otra cosa, incluso si actualmente está ocupado, el código debe deshabilitarlo y volver a habilitarlo explícitamente si hay un fragmento de código que siempre debe ejecutarse de una vez) . Entonces, parece haber una ruta de código que solo se invoca desde este comportamiento particular en el que Apple no deshabilita correctamente la preferencia, lo que lleva a que un subproceso realice el mismo bloqueo de giro dos veces, lo que hace que se agote el tiempo de espera porque el contexto anterior ya no se ejecuta y No puedo desbloquear el spinlock nuevamente.

El problema de Spinlock Timeout Panic ha existido desde que la dopamina estuvo disponible por primera vez y continúa hasta el día de hoy a pesar de muchos intentos de solucionar el problema. Dicho esto, abrir el diálogo para que más personas lo vean y contribuyan es el paso correcto hacia adelante, ya que facilita que más mentes intercambien ideas sobre el problema y una posible solución.

Fröder explica su próxima idea para intentar frustrar el problema en un comentario posterior:

Entonces, el siguiente paso para intentar solucionarlo sería encontrar la estructura vm_page de una página DSC en la memoria del kernel; hasta ahora, todos mis intentos de encontrar dicha estructura han fallado.

Si bien todavía no me ha afectado directamente, será interesante ver si Fröder es capaz de resolver el problema de Spinlock Timeout Panic. Parece ser más frecuente para los usuarios que instalan más ajustes de jailbreak que enlazan funciones de C. Podría ser simplemente que mi dispositivo de prueba no tenga muchos ajustes instalados para desencadenar el problema, pero sé que hay muchos jailbreakers que instalan toneladas de ajustes de jailbreak , más de los que yo jamás instalaría.

Ver también: Cómo hacer jailbreak a dispositivos A12-A15 con iOS y iPadOS 15.0-15.4.1 con dopamina

¿Alguna vez te ha afectado un pánico de tiempo de espera de Spinlock descrito como una pantalla rosa antes de un reinicio repentino mientras usas el jailbreak de dopamina? Háganos saber en la sección de comentarios a continuación.