Vývojář dopaminového jailbreaku diskutuje o nepolapitelném problému Spinlock Timeout Panic
The dopamin nástroj útěk z vězení pro zařízení A12-A15 se systémem iOS & iPadOS 15.0-15.4.1 je jediný nejnovější útěk z vězení dostupný pro jakékoli zařízení novější než iPhone X v tomto okamžiku. Jak už bylo řečeno, není žádným překvapením, že je to oblíbená volba jailbreakery dnes.
Ale pokud používáte Dopamin nebo sledujete projekt od jeho počátku, pravděpodobně jste již několikrát slyšeli určité slovo, které hodil kolem sebe hlavní vývojář projektu Lars Fröder ( @opa334dev ) a uživatelé: Spinlock.
Ve skutečnosti existuje známý problém, který ovlivňuje útěk z vězení s dopaminem, nazývaný panika s časovým limitem Spinlock, a nakonec způsobí, že zařízení uživatele zobrazí růžovou obrazovku a poté se restartuje zdánlivě nevyprovokovaným způsobem. Problém byl po technické stránce popsán takto:
Zdá se, že mapování na spustitelné stránky dyld_shared_cache spouští chování okrajových případů v PPL, které někdy způsobí časový limit na spinlocku stránky paměti, což vede k panice jádra.
Čím více vylepšení, které jsou nainstalovány funkce hook C, a čím více procesů se do nich vloží, tím častěji se toto chování zdá být spouštěno.
Zdá se, že tento problém by mohl být vyřešen zapojením všech stránek, které byly připojeny, ale uživatelský prostor nemůže přijmout takový zámek a nalezení objektu vm_page v paměti jádra k přímému otočení drátového bitu se ukazuje jako obtížné.
Vzhledem k tomu, že jsem nikdy osobně nezažil jeden z těchto problémů na svém dopaminovém zařízení, bylo těžké vysvětlit, jak to vypadá nebo kdy se to stane, ale mluvil jsem s Fröderem a zeptal jsem se, co si myslí, že by to mohlo způsobit, abych se dozvěděl více o tom, jak se to snaží řešit.
Fröderova odpověď byla poučná pro netechnické lidi, jako jsem já a pravděpodobně mnoho dalších v komunitě útěk z vězení a od té doby byla publikováno na stránce vydání GitHubu aby veřejnost viděla. Úplná odpověď, citovaná níže, odhaluje Fröderovo chápání problému Spinlock Timeout Panic:
Zde je pokus o hlubší vysvětlení problému, abych mu v současné době nejlépe porozuměl. Mějte na paměti, že je založen na předpokladech, které v podstatě nelze ověřit.
Ve vícevláknovém systému se tedy používají „zámky“, aby se zabránilo vzájemnému rušení dvou vláken. Tím může jedno vlákno získat zámek, provést úpravu a odemknout jej. Když je uzamčeno, další vlákno, které se pokouší získat zámek, počká, dokud nebude objekt znovu odemčen.
Spinlock je v podstatě to samé, jen se používá pro výkon relevantní věci a hlavní rozdíl je v tom, že spinlock může vypršet, pokud něco trvá uzamčení příliš dlouho, zatímco se jiné vlákno pokouší získat zámek. Takže při získání zámku a objekt je již zamčený, bude čekat na několik zaškrtnutí a pokud se objekt v tomto časovém rámci neodemkne, vyprší časový limit.
Tento mechanismus sám o sobě není problém, problém s ním souvisí Paměť stránky. Každá paměťová stránka (která popisuje oblast 16kB RAM) má spinlock, takže nedochází k problémům, když se více procesů pokouší získat stejnou stránku současně.
Konkrétní stránky lze mapovat do více procesů (např. pokud oba načítají stejnou knihovnu), znovu použijí stejnou stránku, aby šetřily paměť. Tweaky chtějí takovou paměť přepsat na základě jednotlivých procesů, takže musí nejprve vytvořit procesně specifickou kopii existujícího mapování a namapovat ji na něj, takže např. jednu stránku lze upravit v jednom procesu, zatímco v ostatních procesech zůstane zásoba. Zdá se, že k problému dochází konkrétně při mapování v horní části stránky, která se nachází uvnitř dyld_shared_cache.
Problém je nyní v tom, že Apple pravděpodobně nikdy netestoval tento druh hákování a zjevně, když to uděláte v mnoha procesech, může způsobit, že původní stránka (ta ze sdíleného mapování) bude stránkována, protože se aktivně nepoužívá. . Stránkováním se stránka v podstatě odstraní z paměti RAM a při opětovném přístupu k ní bude znovu načtena. Na skladovém systému se to nestane, protože nic nebylo připojeno.
Nyní se zdá, že hlavní příčinou je něco, co se pokouší odstránkovat dříve odstráněnou sdílenou/spustitelnou stránku zpět, což vyvolá problém s preempcí, kdy jedno vlákno převezme spinlock, a když ho má, dostane se preemptováno do jiného kontextu, který také převezme stejný spinlock (Preempce je v podstatě mechanismus, který umožňuje, aby jedno vlákno bylo použito pro něco jiného, i když je aktuálně zaneprázdněné, kód jej musí explicitně zakázat a znovu povolit, pokud existuje kus kódu, který by měl být vždy spuštěn najednou) . Zdá se tedy, že existuje jedna kódová cesta, která je vyvolána pouze z tohoto konkrétního chování, kdy Apple správně nezakáže preempci, což vede k tomu, že jedno vlákno vezme stejný spinlock dvakrát, což způsobí, že vyprší časový limit, protože starý kontext se již nespouští a nelze spinlock znovu odemknout.
Pokud jde o zmírnění, zkusil jsem si pohrát s proměnnými souvisejícími se spinlockem, abych zvýšil práh, který je potřeba k tomu, aby vypršel časový limit, bohužel nás Apple podělal, protože vše, co s tím souvisí, je chráněno KTRR, pro které nemáme bypass. Myslím, že správnou opravou by bylo „odpojit“ (odpojení stránky zabrání tomu, aby byla stránkována) každou připojenou stránku, než bude přepsána, aby se zajistilo, že k vyřazení stránky nikdy nedojde, a tím i cesta kódu, která je součástí problém se nespustí, zatím jsem zkoušel spoustu věcí, ale zdá se, že je přímo nemožné získat takové zapojení z uživatelského prostoru, takže to musí být provedeno uvnitř jádra. Struktury zapojené do tohoto specifického sdíleného mapování, které způsobuje problém, jsou bohužel velmi spletité a já ještě musím najít způsob, jak získat správný objekt stránky, na který bych použil kabeláž.
Problém Spinlock Timeout Panic existuje od doby, kdy byl poprvé k dispozici dopamin, a přetrvává dodnes navzdory mnoha pokusům problém vyřešit. Otevření dialogu pro více lidí, aby jej viděli a přispěli k němu, je však správným krokem vpřed, protože více myslím usnadňuje brainstorming o problému a možném řešení.
Fröder vysvětluje jejich další nápad, jak se pokusit problém zmařit, v následném komentáři:
Takže dalším krokem, jak to zkusit a opravit, by bylo najít strukturu vm_page stránky DSC v paměti jádra, zatím všechny mé pokusy najít takovou strukturu selhaly.
I když mě to zatím přímo neovlivnilo, bude skutečně zajímavé zjistit, zda je Fröder schopen vyřešit problém Spinlock Timeout Panic. Zdá se, že je častější pro uživatele, kteří instalují více vylepšení útěku z vězení, která zachycují funkce C. Je možné, že na mém testovacím zařízení není nainstalováno mnoho vylepšení, které by problém vyvolaly, ale vím, že existuje mnoho útěkářů, kteří instalují spoustu vylepšení útěku z vězení – víc než kdy jindy.
Viz také: Jak provést útěk z vězení na zařízeních A12-A15 se systémem iOS a iPadOS 15.0-15.4.1 pomocí dopaminu
Zasáhla vás někdy panika s časovým limitem Spinlock popisovaná jako růžová obrazovka před náhlým restartem při používání dopaminového útěku z vězení? Dejte nám vědět v sekci komentářů níže.