Инструмент для джейлбрейка Dopamine для устройств A12-A15 под управлением iOS и iPadOS 15.0-15.4.1 — это единственный последний джейлбрейк, доступный на данный момент для любого устройства новее, чем iPhone X. Однако неудивительно, что сегодня это популярный выбор среди взломщиков .
Но если вы использовали Dopamine или следили за проектом с момента его создания, то вы, вероятно, неоднократно слышали определенное слово, произнесенное ведущим разработчиком проекта Ларсом Фрёдером (@opa334dev) и пользователями: Spinlock.
Действительно, существует известная проблема, которая влияет на джейлбрейк Dopamine, называемая Spinlock Timeout Panic, и в конечном итоге она приводит к тому, что на устройстве пользователя отображается розовый экран, а затем он перезагружается, казалось бы, неспровоцированным образом. Технически проблема описана следующим образом:
Сопоставление поверх исполняемых страниц dyld_shared_cache, по-видимому, вызывает поведение в крайнем случае в PPL, которое иногда вызывает тайм-аут спин-блокировки страницы памяти, что приводит к панике ядра.
Чем больше настроек, которые перехватывают функции C, установлено, и чем больше процессов они внедряют, тем чаще срабатывает такое поведение.
Похоже, что эту проблему можно решить, подключив все подключенные страницы, но пользовательское пространство не может принять такую блокировку, и найти объект vm_page в памяти ядра, чтобы напрямую перевернуть подключенный бит, оказывается сложно.
Поскольку я никогда лично не сталкивался ни с одной из этих проблем на своем дофаминовом устройстве, мне было трудно объяснить, как это выглядит и когда это происходит, но я поговорил с Фрёдером, чтобы спросить, что, по их мнению, может быть причиной этого, чтобы узнать больше о том, как это происходит. они пытаются решить эту проблему.
Ответ Фредера был познавательным для людей, не разбирающихся в технических вопросах, таких как я и, возможно, для многих других членов сообщества джейлбрейков, и с тех пор был опубликован на странице выпуска GitHub для всеобщего обозрения. Полный ответ, приведенный ниже, раскрывает понимание Фредером проблемы паники тайм-аута Spinlock:
Вот попытка более глубокого объяснения проблемы, насколько я понимаю ее на данный момент. Имейте в виду, что оно основано на предположениях, которые в принципе невозможно проверить.
Таким образом, в многопоточной системе «блокировки» используются для предотвращения взаимодействия двух потоков друг с другом. Таким образом, один поток может получить блокировку, внести изменения и разблокировать ее. Пока объект заблокирован, другой поток, пытающийся получить блокировку, будет ждать, пока объект не будет снова разблокирован.
Спин-блокировка, по сути, то же самое, она используется только для задач, связанных с производительностью, и основное отличие состоит в том, что спин-блокировка может истечь по тайм-ауту, если что-то занимает блокировку слишком долго, пока другой поток пытается получить блокировку. Таким образом, при получении блокировки, когда объект уже заблокирован, он будет ждать несколько тиков, и если объект не будет разблокирован в течение этого периода времени, время ожидания истечет.
Этот механизм сам по себе не является проблемой, проблема связана со страницами памяти . Каждая страница памяти (которая описывает область ОЗУ размером 16 КБ) имеет спин-блокировку, поэтому не возникает проблем, когда несколько процессов пытаются одновременно получить одну и ту же страницу.
Определенные страницы могут быть сопоставлены с несколькими процессами (например, если оба загружают одну и ту же библиотеку), они повторно используют одну и ту же страницу для экономии памяти. Твики хотят перезаписать такую память для каждого процесса, поэтому им нужно сначала сделать копию существующего сопоставления для конкретного процесса и сопоставить ее поверх нее, чтобы, например, одна страница могла быть изменена в одном процессе, оставаясь при этом в исходном состоянии. в других процессах. Кажется, проблема возникает именно при сопоставлении поверх страницы, которая находится внутри dyld_shared_cache.
Проблема теперь в том, что Apple, вероятно, никогда не тестировала этот вид перехвата, и, очевидно, когда вы делаете это во многих процессах, это может привести к выгрузке исходной страницы (той, которая является общим сопоставлением), потому что она активно не используется. . Выгрузка страницы по существу удаляет ее из оперативной памяти, и при повторном доступе к ней она будет загружена снова. На стоковой системе этого не произойдет, потому что ничего не подцеплено.
Теперь основная причина, по-видимому, заключается в попытке вернуть ранее выгруженную общую/исполняемую страницу обратно. Это вызывает проблему вытеснения, когда один поток принимает спин-блокировку, и пока она у него есть, он выгружается в другой контекст, который также принимает та же спин-блокировка (по сути, вытеснение — это механизм, который позволяет использовать один поток для чего-то другого, даже если он в данный момент занят, код должен явно отключить и повторно включить его, если есть фрагмент кода, который всегда должен выполняться за один раз) . Таким образом, похоже, что существует один путь кода, который вызывается только из этого конкретного поведения, когда Apple неправильно отключает вытеснение, что приводит к тому, что один поток принимает одну и ту же спин-блокировку два раза, что приводит к тайм-ауту, потому что старый контекст больше не выполняется и не могу снова разблокировать спинлок.
Проблема Spinlock Timeout Panic возникла с тех пор, как впервые стал доступен допамин, и продолжает сохраняться по сей день, несмотря на многочисленные попытки решить эту проблему. При этом открытие диалога для того, чтобы больше людей могли его увидеть и внести в него свой вклад, является правильным шагом вперед, поскольку это облегчает большему количеству умов мозговой штурм проблемы и возможного решения.
Фрёдер объясняет их следующую идею, как попытаться решить эту проблему, в последующем комментарии:
Итак, следующим шагом в попытке исправить это будет поиск структуры vm_page страницы DSC в памяти ядра, до сих пор все мои попытки найти такую структуру не увенчались успехом.
Хотя это еще не коснулось меня напрямую, действительно будет интересно посмотреть, сможет ли Фредер решить проблему паники тайм-аута Spinlock. Кажется, это более распространено среди пользователей, которые устанавливают больше твиков для джейлбрейка, которые перехватывают функции C. Возможно, на моем тестовом устройстве не установлено много настроек, которые могли бы вызвать эту проблему, но я знаю, что есть много джейлбрейкеров, которые устанавливают тонны джейлбрейк-твиков – больше, чем я когда- либо .
См. также: Как сделать джейлбрейк устройств A12–A15 под управлением iOS и iPadOS 15.0–15.4.1 с помощью допамина.
Вы когда-нибудь сталкивались с паникой Spinlock Timeout Panic, описываемой как розовый экран перед внезапной перезагрузкой при использовании джейлбрейка Dopamine? Дайте нам знать в разделе комментариев ниже.