Dopamínový vývojár útek z väzenia diskutuje o nepolapiteľnom probléme Spinlock Timeout Panic
The dopamín nástroj na útek z väzenia pre zariadenia A12-A15 so systémom iOS a iPadOS 15.0-15.4.1 je jediný najnovší útek z väzenia dostupný pre akékoľvek zariadenie novšie ako iPhone X v tomto okamihu. Napriek tomu nie je prekvapením, že je to populárna voľba jailbreakers dnes.
Ak však používate dopamín alebo sledujete projekt od jeho začiatku, pravdepodobne ste už niekoľkokrát počuli určité slovo od hlavného vývojára projektu Larsa Frödera ( @opa334dev ) a používatelia: Spinlock.
V skutočnosti existuje známy problém, ktorý ovplyvňuje útek z väzenia s dopamínom, nazývaný panika s časovým limitom Spinlock, a v konečnom dôsledku má za následok, že zariadenie používateľa zobrazuje ružovú obrazovku a potom sa reštartuje zdanlivo nevyprovokovaným spôsobom. Problém bol popísaný v technických termínoch takto:
Zdá sa, že mapovanie na spustiteľné stránky dyld_shared_cache spúšťa správanie okrajových prípadov v PPL, ktoré niekedy spôsobí časový limit spinlocku stránky pamäte, čo vedie k panike jadra.
Čím viac vylepšení, ktoré sú nainštalované funkcie hook C, a čím viac procesov sa do nich vloží, tým častejšie sa zdá, že sa toto správanie spúšťa.
Zdá sa, že tento problém by sa dal vyriešiť zapojením všetkých stránok, ktoré boli pripojené, ale používateľský priestor nemôže prijať takýto zámok a nájsť objekt vm_page v pamäti jadra na priame prevrátenie káblového bitu sa ukazuje ako ťažké.
Keďže som nikdy osobne nezažil jeden z týchto problémov na svojom dopamínovom zariadení, bolo ťažké vysvetliť, ako to vyzerá alebo kedy sa to stane, ale porozprával som sa s Fröderom a spýtal som sa, čo si myslia, že by to mohlo spôsobiť, aby som sa dozvedel viac o tom, ako snažia sa to riešiť.
Fröderova odpoveď bola poučná pre netechnických ľudí, ako som ja a pravdepodobne aj mnohí ďalší v komunite útek z väzenia a odvtedy zverejnené na stránke vydania GitHub aby verejnosť videla. Úplná odpoveď, citovaná nižšie, odhaľuje Fröderovo chápanie problému Spinlock Timeout Panic:
Tu je pokus o hlbšie vysvetlenie problému, aby som to pochopil najlepšie. Majte na pamäti, že je založený na predpokladoch, ktoré je v podstate nemožné overiť.
Takže vo viacvláknovom systéme sa používajú „zámky“, aby sa zabránilo vzájomnému rušeniu dvoch vlákien. Tým môže jedno vlákno získať zámok, vykonať úpravu a odomknúť ho. Keď je zamknuté, ďalšie vlákno, ktoré sa pokúša získať zámok, počká, kým sa objekt znova neodomkne.
Spinlock je v podstate to isté, len sa používa na výkon relevantné veci a hlavný rozdiel je v tom, že spinlock môže vypršať, ak niečo trvá uzamknutiu príliš dlho, kým sa iné vlákno pokúša získať zámok. Takže pri získaní zámku a objekt je už zamknutý, bude čakať na niekoľko tiknutí a ak sa objekt v tomto časovom rámci neodomkne, vyprší časový limit.
Tento mechanizmus sám osebe nie je problém, problém s ním súvisí Pamäť stránky. Každá pamäťová stránka (ktorá popisuje oblasť 16 kB RAM) má spinlock, takže nedochádza k problémom, keď sa viaceré procesy pokúšajú získať rovnakú stránku v rovnakom čase.
Špecifické stránky môžu byť mapované do viacerých procesov (napr. ak oba načítajú rovnakú knižnicu), znova použijú rovnakú stránku, aby sa ušetrila pamäť. Tweaky chcú prepísať takú pamäť na základe jednotlivých procesov, takže musia najprv vytvoriť procesne špecifickú kópiu existujúceho mapovania a namapovať ju na ňu, aby napr. jedna strana môže byť upravená v jednom procese, zatiaľ čo zostávajúce zásoby v ostatných procesoch. Zdá sa, že problém sa vyskytuje konkrétne pri mapovaní na vrch stránky, ktorá sa nachádza vo vnútri dyld_shared_cache.
Problém je teraz v tom, že Apple pravdepodobne nikdy netestoval tento druh háčkovania a očividne, keď to robíte v mnohých procesoch, môže spôsobiť, že pôvodná stránka (jedna zo zdieľaného mapovania) bude stránkovaná, pretože sa aktívne nepoužíva. . Odstránením stránky sa stránka v podstate odstráni z pamäte RAM a pri opätovnom prístupe sa znova načíta. Na skladovom systéme sa to nestane, pretože nič nebolo zahnuté.
Teraz sa zdá, že hlavnou príčinou je niečo, čo sa pokúša odstrániť predtým odstránenú zdieľanú/spustiteľnú stránku späť, čo spustí problém s preempciou, keď jedno vlákno prevezme spinlock, a hoci ho má, dostane sa do iného kontextu, ktorý tiež prevezme rovnaký spinlock (Preempcia je v podstate mechanizmus, ktorý umožňuje jedno vlákno použiť na niečo iné, aj keď je momentálne zaneprázdnené, kód ho musí explicitne zakázať a znova povoliť, ak existuje časť kódu, ktorá by sa mala vždy spustiť naraz) . Zdá sa teda, že existuje jedna kódová cesta, ktorá je vyvolaná iba z tohto konkrétneho správania, kde Apple správne nezakáže preempciu, čo vedie k tomu, že jedno vlákno dvakrát zablokuje rovnaký spinlock, čo spôsobí, že vyprší časový limit, pretože starý kontext sa už nespúšťa a nemôže znova odomknúť spinlock.
Pokiaľ ide o zmiernenie, pokúsil som sa pohrať s premennými súvisiacimi so spinlockom, aby som zvýšil prah, ktorý je potrebný na to, aby vypršal časový limit, bohužiaľ nás Apple posral, pretože všetko, čo s tým súvisí, je chránené KTRR, pre ktorý nemáme bypass. Myslím, že správnou opravou by bolo „odpojiť“ (prepojenie stránky zabráni jej odstráneniu) každú pripojenú stránku pred jej prepísaním, aby sa zaistilo, že k vytlačeniu stránky nikdy nedôjde, a teda cesta kódu, ktorá je súčasťou problém sa nespustí, zatiaľ som vyskúšal veľa vecí, ale zdá sa, že je priamo nemožné získať takéto vedenie z užívateľského priestoru, takže to musí byť vykonané v jadre. Žiaľ, štruktúry zapojené do tohto špecifického zdieľaného mapovania, ktoré spôsobuje problém, sú veľmi spletité a ešte musím nájsť spôsob, ako získať správny objekt stránky, na ktorý by som mal použiť zapojenie.
Problém Spinlock Timeout Panic je tu odkedy bol dopamín prvýkrát dostupný a pretrváva dodnes napriek mnohým pokusom na vyriešenie problému. Otvorenie dialógu, aby ho videlo a prispelo k nemu viac ľudí, je správnym krokom vpred, pretože viacerým ľuďom uľahčuje brainstorming o probléme a možnom riešení.
Fröder vysvetľuje ich ďalší nápad, ako sa pokúsiť zmariť problém, v následnom komentári:
Takže ďalším krokom pri pokuse o opravu by bolo nájsť štruktúru vm_page stránky DSC v pamäti jadra, zatiaľ všetky moje pokusy nájsť takúto štruktúru zlyhali.
Aj keď ma to ešte priamo neovplyvnilo, bude skutočne zaujímavé zistiť, či Fröder dokáže vyriešiť problém Spinlock Timeout Panic. Zdá sa, že je rozšírenejší pre používateľov, ktorí inštalujú viac vylepšení útek z väzenia, ktoré pripájajú funkcie C. Je možné, že na mojom testovacom zariadení nie je nainštalovaných veľa vylepšení na spustenie problému, ale viem, že existuje veľa útek z väzenia, ktorí inštalujú veľa vylepšenia útek z väzenia – viac ako kedykoľvek predtým.
Pozri tiež: Ako vykonať útek z väzenia na zariadeniach A12-A15 so systémom iOS a iPadOS 15.0-15.4.1 s dopamínom
Boli ste niekedy ovplyvnení panikou Spinlock Timeout Panic opísanou ako ružová obrazovka pred náhlym reštartom počas používania dopamínového útek z väzenia? Dajte nám vedieť v sekcii komentárov nižšie.