Dopamine-jailbreakontwikkelaar bespreekt ongrijpbaar Spinlock Timeout Panic-probleem
De Dopamine jailbreaktool voor A12-A15-apparaten met iOS en iPadOS 15.0-15.4.1 is de nieuwste jailbreak die op dit moment beschikbaar is voor elk apparaat dat nieuwer is dan de iPhone X. Dat gezegd hebbende, is het geen verrassing dat het een populaire keuze is jailbreakers Vandaag.
Maar als je Dopamine gebruikt of het project sinds het begin volgt, dan heb je waarschijnlijk al een paar keer een bepaald woord horen rondslingeren door projectleider Lars Fröder ( @opa334dev ) en gebruikers: Spinlock.
Er is inderdaad een bekend probleem dat van invloed is op de Dopamine-jailbreak, genaamd Spinlock Timeout Panic, en dit resulteert er uiteindelijk in dat het apparaat van een gebruiker een roze scherm weergeeft en vervolgens op een schijnbaar niet-uitgelokte manier opnieuw opstart. Het probleem is in technische termen als volgt beschreven:
Het in kaart brengen bovenop uitvoerbare pagina's van dyld_shared_cache lijkt een randgevalgedrag in de PPL te activeren dat soms een time-out veroorzaakt op de spinlock van een geheugenpagina, resulterend in een kernelpaniek.
Hoe meer tweaks die C-functies hooken, zijn geïnstalleerd en hoe meer processen daarin worden geïnjecteerd, hoe vaker dit gedrag lijkt te worden geactiveerd.
Het lijkt erop dat dit probleem kan worden opgelost door alle pagina's die zijn gekoppeld te bedraden, maar de gebruikersruimte kan zo'n vergrendeling niet aan en het vinden van het vm_page-object in het kernelgeheugen om het bedrade bit direct om te draaien blijkt moeilijk te zijn.
Omdat ik persoonlijk nog nooit een van deze problemen heb ervaren op mijn Dopamine-apparaat, was het moeilijk uit te leggen hoe dit eruit ziet of wanneer het gebeurt, maar ik heb wel met Fröder gesproken om te vragen wat zij denken dat dit zou kunnen veroorzaken om meer te leren over hoe ze proberen het aan te pakken.
De reactie van Fröder was verhelderend voor niet-technische mensen zoals ik en waarschijnlijk vele anderen in de jailbreakgemeenschap en is sindsdien gepubliceerd op een GitHub-probleempagina zodat het publiek het kan zien. Het volledige antwoord, dat hieronder wordt geciteerd, onthult Fröders begrip van het Spinlock Timeout Panic-probleem:
Hier is een poging tot een meer diepgaande uitleg van de kwestie, voor zover ik er op dit moment het beste van begrijp. Houd er rekening mee dat het gebaseerd is op aannames die in principe onmogelijk te verifiëren zijn.
In een systeem met meerdere threads worden dus “locks” gebruikt om te voorkomen dat twee threads elkaar hinderen. Hierdoor kan één draad een vergrendeling verkrijgen, de wijziging aanbrengen en deze ontgrendelen. Terwijl het vergrendeld is, zal een andere thread die de vergrendeling probeert te verkrijgen, wachten totdat het object weer is ontgrendeld.
Een spinlock is in wezen hetzelfde, alleen gebruikt voor prestatierelevante zaken en het belangrijkste verschil is dat een spinlock een time-out kan krijgen als iets de vergrendeling te lang duurt terwijl een andere thread de vergrendeling probeert te verkrijgen. Dus bij het verkrijgen van een slot en het object is al vergrendeld, wacht het een paar tikken en als het object binnen dat tijdsbestek niet wordt ontgrendeld, treedt er een time-out op.
Dit mechanisme op zichzelf is niet het probleem, het heeft er mee te maken geheugen Pagina's. Elke geheugenpagina (die een gebied van 16 kB RAM beschrijft) heeft een spinlock, zodat er geen problemen optreden als meerdere processen tegelijkertijd dezelfde pagina proberen te verkrijgen.
Specifieke pagina's kunnen worden toegewezen aan meerdere processen (als beide bijvoorbeeld dezelfde bibliotheek laden), gebruiken ze dezelfde pagina opnieuw om geheugen te besparen. Tweaks willen dergelijk geheugen per proces overschrijven, dus moeten ze eerst een processpecifieke kopie maken van de bestaande mapping en deze daarbovenop in kaart brengen, zodat b.v. één pagina kan in het ene proces worden aangepast terwijl er in de andere processen voorraad blijft. Het probleem lijkt zich specifiek voor te doen bij het in kaart brengen bovenop een pagina die zich in de dyld_shared_cache bevindt.
Het probleem is nu dat Apple dit soort hooking waarschijnlijk nooit heeft getest en blijkbaar, als je het in veel processen doet, kan dit ervoor zorgen dat de originele pagina (die van de gedeelde mapping) wordt weggebladerd, omdat deze niet actief wordt gebruikt . Als u een pagina uitbladert, wordt deze feitelijk uit het RAM verwijderd en wanneer deze opnieuw wordt geopend, wordt deze opnieuw geladen. Op een voorraadsysteem zal dit niet gebeuren omdat er niets aan is verslaafd.
Nu lijkt de hoofdoorzaak iets te zijn dat probeert een eerder uitgebladerde gedeelde/uitvoerbare pagina weer in te voeren. Dit veroorzaakt een voorrangsprobleem waarbij één thread de spinlock overneemt en terwijl deze dat heeft, wordt deze overgezet naar een andere context die ook de dezelfde spinlock (Preemption is in wezen een mechanisme waarmee één thread voor iets anders kan worden gebruikt, zelfs als deze momenteel bezet is, code moet deze expliciet uitschakelen en opnieuw inschakelen als er een stukje code is dat altijd in één keer moet worden uitgevoerd) . Er lijkt dus één codepad te zijn dat alleen wordt aangeroepen vanuit dit specifieke gedrag waarbij Apple preemption niet correct uitschakelt, wat ertoe leidt dat één thread tweemaal dezelfde spinlock gebruikt, waardoor er een time-out optreedt omdat de oude context niet meer wordt uitgevoerd en kan de spinlock niet meer ontgrendelen.
Wat betreft het verzachten ervan: ik heb geprobeerd met spinlock-gerelateerde variabelen te rommelen om de drempel die nodig is om de time-out te laten verlopen hoger te maken. Helaas heeft Apple ons genaaid omdat alles wat daarmee verband houdt KTRR-beveiligd is, waarvoor we geen bypass hebben. Ik denk dat de juiste oplossing zou zijn om elke pagina die moet worden gekoppeld, te 'bedraden' (door een pagina te bedraden, wordt voorkomen dat deze wordt uitgewisseld) voordat deze wordt overschreven om ervoor te zorgen dat de pagina nooit wordt uitgebladerd en daarom het codepad dat betrokken is bij de het probleem treedt niet op, ik heb tot nu toe een heleboel dingen geprobeerd, maar het lijkt erop dat het ronduit onmogelijk is om een dergelijke bedrading vanuit de gebruikersruimte te verkrijgen, dus het moet binnen de kernel worden gedaan. Helaas zijn de structuren die betrokken zijn bij deze specifieke gedeelde mapping die het probleem veroorzaakt erg ingewikkeld en moet ik nog een manier vinden om het juiste pagina-object te verkrijgen waarop de bedrading kan worden toegepast.
Het Spinlock Timeout Panic-probleem bestaat al sinds Dopamine voor het eerst beschikbaar kwam en blijft tot op de dag van vandaag bestaan ondanks vele pogingen om het probleem op te lossen. Dat gezegd hebbende, is het openen van de dialoog zodat meer mensen het kunnen zien en eraan kunnen bijdragen, de juiste stap voorwaarts, omdat het het voor meer geesten gemakkelijker maakt om over het probleem en een mogelijke oplossing te brainstormen.
Fröder legt hun volgende idee uit om te proberen de kwestie te dwarsbomen in een vervolgcommentaar:
Dus de volgende stap om dit probleem op te lossen zou het vinden van de vm_page-structuur van een DSC-pagina in het kernelgeheugen zijn. Tot nu toe zijn al mijn pogingen om zo'n structuur te vinden mislukt.
Hoewel het mij nog niet direct heeft beïnvloed, zal het inderdaad interessant zijn om te zien of Fröder het Spinlock Timeout Panic-probleem kan oplossen. Het lijkt vaker voor te komen bij gebruikers die meer jailbreak-tweaks installeren die C-functies hooken. Het kan zijn dat er op mijn testapparaat niet veel aanpassingen zijn geïnstalleerd om het probleem te veroorzaken, maar ik weet dat er veel jailbreakers zijn die er talloze installeren jailbreak-aanpassingen – meer dan ik ooit zou doen.
Zie ook: Hoe A12-A15-apparaten met iOS en iPadOS 15.0-15.4.1 te jailbreaken met Dopamine
Heeft u ooit last gehad van een Spinlock Timeout Panic, beschreven als een roze scherm voordat u plotseling opnieuw opstartte terwijl u de Dopamine-jailbreak gebruikte? Laat het ons weten in de opmerkingen hieronder.