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