Разработчикът на допаминов джейлбрейк обсъжда неуловимия проблем с таймаута на Spinlock Panic
The Допамин Инструментът за джейлбрейк за A12-A15 устройства, работещи с iOS и iPadOS 15.0-15.4.1, е единственият най-нов джейлбрейк, наличен за всяко устройство, по-ново от iPhone X към този момент. Като каза това, не е изненада, че това е популярен избор за джейлбрейкъри днес.
Но ако използвате Dopamine или следите проекта от самото му начало, тогава вероятно сте чували определена дума, хвърлена доста пъти от водещия разработчик на проекта Ларс Фрьодер ( @opa334dev ) и потребители: Spinlock.
Наистина, има известен проблем, който засяга Dopamine jailbreak, наречен Spinlock Timeout Panic, и в крайна сметка води до това, че устройството на потребителя показва розов екран и след това се рестартира по привидно непровокиран начин. Проблемът е описан от техническа гледна точка, както следва:
Картографирането върху изпълнимите страници на dyld_shared_cache изглежда задейства поведение на крайния случай в PPL, което понякога причинява изчакване на заключването на страница с памет, което води до паника на ядрото.
Колкото повече ощипвания, които закачат функциите на C, са инсталирани и в колкото повече процеси се инжектират, толкова по-често това поведение изглежда се задейства.
Изглежда, че този проблем може да бъде решен чрез свързване на всички страници, които са били закачени, но потребителското пространство не може да поеме такова заключване и намирането на обекта vm_page в паметта на ядрото, за да се обърне директно кабелния бит, се оказва трудно.
Тъй като никога не съм имал лично един от тези проблеми на моето устройство с допамин, беше трудно да обясня как изглежда това или кога се случва, но все пак говорих с Фрьодер, за да попитам какво според тях може да го причинява, за да науча повече за това как те се опитват да се справят с него.
Отговорът на Фрьодер беше проницателен за нетехнически хора като мен и вероятно много други в общността за джейлбрейк и оттогава е публикувани на страница с проблеми в GitHub за да види публиката. Пълният отговор, цитиран по-долу, разкрива разбирането на Fröder за проблема с Spinlock Timeout Panic:
Ето един опит за по-задълбочено обяснение на проблема според моето най-добро настоящо разбиране за него. Имайте предвид, че се основава на предположения, които по същество е невъзможно да се проверят.
Така че в многонишкова система се използват „ключалки“, за да се предотврати намесата на две нишки една в друга. По този начин една нишка може да получи заключване, да направи модификацията и да я отключи. Докато е заключен, друга нишка, опитваща се да получи заключването, ще изчака, докато обектът бъде отключен отново.
Spinlock е по същество едно и също нещо, само се използва за свързани с производителността неща и основната разлика е, че spinlock може да изтече, ако нещо отнеме заключването твърде дълго, докато друга нишка се опитва да придобие заключването. Така че, когато придобие заключване и обектът вече е заключен, той ще изчака няколко отметки и ако обектът не бъде отключен в този период от време, времето ще изтече.
Този механизъм сам по себе си не е проблемът, проблемът е свързан с памет страници. Всяка страница от паметта (която описва област от 16kB RAM) има спинлок, така че да няма проблеми, когато множество процеси се опитват да придобият една и съща страница едновременно.
Конкретни страници могат да бъдат картографирани в множество процеси (напр. ако и двете зареждат една и съща библиотека), те използват повторно една и съща страница, за да спестят памет. Ощипванията искат да презапишат такава памет на базата на процес, така че те трябва първо да направят специфично за процеса копие на съществуващото картографиране и да го картографират върху него, така че напр. една страница може да бъде модифицирана в един процес, докато остава наличност в другите процеси. Изглежда, че проблемът възниква конкретно при картографиране върху страница, която се намира в dyld_shared_cache.
Проблемът сега е, че Apple вероятно никога не е тествал този вид закачане и очевидно, когато го правите в много процеси, това може да доведе до извеждане на оригиналната страница (тази от споделеното картографиране), защото не се използва активно . Странирането на страница по същество я премахва от RAM и когато се отвори отново, тя ще бъде заредена отново. На фондова система това няма да се случи, защото нищо не е закачено.
Сега основната причина изглежда е нещо, което се опитва да върне обратно на страниците споделена/изпълнима страница, която преди това е излязла, това задейства проблем с изпреварване, при което една нишка взема заключването на въртене и докато има това, тя се изпреварва към различен контекст, който също отнема същото spinlock (Изпреварването по същество е механизъм, който позволява една нишка да се използва за нещо друго, дори ако в момента е заета, кодът трябва изрично да я деактивира и активира отново, ако има част от кода, която винаги трябва да се изпълнява наведнъж) . Така че изглежда има един кодов път, който се извиква само от това конкретно поведение, при което Apple не деактивира правилно изпреварването, което води до една нишка, която взема едно и също блокиране два пъти, което го прави изчакване, защото старият контекст вече не се изпълнява и не може да отключи спинлок отново.
Що се отнася до смекчаването му, опитах се да се забъркам със свързаните със спинлок променливи, за да направя прага, който е необходим за изчакване, по-висок, за съжаление Apple ни прецака, защото всичко, свързано с това, е защитено с KTRR, за което нямаме байпас. Предполагам, че правилното решение би било да се „свърже“ (свързването на страница предотвратява извеждането ѝ) на всяка страница, която трябва да бъде закачена, преди да бъде презаписана, за да се гарантира, че извеждането на страницата никога не се случва и следователно кодовият път, включен в проблемът не се задейства, опитах куп неща досега, но изглежда, че е направо невъзможно да се придобие такова окабеляване от потребителското пространство, така че трябва да се направи вътре в ядрото. За съжаление, структурите, включени в това конкретно споделено картографиране, което причинява проблема, са много сложни и все още не съм намерил начин да получа правилния обект на страница, към който да приложа окабеляването.
Проблемът Spinlock Timeout Panic съществува, откакто допаминът стана достъпен за първи път и продължава да съществува до ден днешен въпреки многото опити за отстраняване на проблема. Като каза това, отварянето на диалога, за да могат повече хора да го видят и да допринесат, е правилната стъпка напред, тъй като улеснява повече умове да обмислят проблема и възможно решение.
Фрьодер обяснява следващата им идея за опит за осуетяване на проблема в последващ коментар:
Така че следващата стъпка, за да се опитам да го поправя, би била да намеря структурата vm_page на DSC страница в паметта на ядрото, досега всичките ми опити да намеря такава структура са неуспешни.
Въпреки че все още не ме е засегнало директно, наистина ще бъде интересно да видим дали Fröder е в състояние да разреши проблема с Spinlock Timeout Panic. Изглежда, че е по-разпространено за потребители, които инсталират повече настройки за джейлбрейк, които закачат C функции. Възможно е моето тестово устройство да няма инсталирани много настройки, които да задействат проблема, но знам, че има много джейлбрейкъри, които инсталират тонове настройки за бягство от затвора – повече, отколкото някога бих направил.
Вижте също: Как да джейлбрейкнете A12-A15 устройства, работещи с iOS и iPadOS 15.0-15.4.1 с допамин
Били ли сте някога засегнати от Spinlock Timeout Panic, описан като розов екран преди внезапно рестартиране, докато използвате Dopamine Jailbreak? Уведомете ни в секцията за коментари по-долу.