Det Dopamin jailbreak-værktøj til A12-A15-enheder, der kører iOS & iPadOS 15.0-15.4.1, er det seneste jailbreak, der er tilgængeligt for enhver enhed nyere end iPhone X på dette tidspunkt. Når det er sagt, er det ingen overraskelse, at det er et populært valg for jailbreakers i dag.
Men hvis du har brugt Dopamin eller fulgt projektet siden dets start, så har du sandsynligvis hørt et bestemt ord smidt rundt en del gange af projektlederudvikler Lars Fröder ( @opa334dev ) og både brugere: Spinlock.
Der er faktisk et kendt problem, der påvirker Dopamin-jailbreaket kaldet en Spinlock Timeout Panic, og det resulterer i sidste ende, at en brugers enhed viser en lyserød skærm og derefter genstarter på en tilsyneladende uprovokeret måde. Problemet er blevet beskrevet i tekniske termer som følger:
Kortlægning oven på dyld_shared_cache eksekverbare sider ser ud til at udløse en edge case-adfærd i PPL'en, der nogle gange forårsager en timeout på spinlocken på en hukommelsesside, hvilket resulterer i en kernepanik.
Jo flere tweaks der er installeret hook C-funktioner, og jo flere processer de injicerer i, jo oftere ser denne adfærd ud til at blive udløst.
Det ser ud til, at dette problem kunne løses ved at nedbryde alle sider, der er blevet tilsluttet, men brugerområdet kan ikke tage sådan en lås, og det viser sig at være svært at finde vm_page-objektet i kernehukommelsen for at vende den kablede bit direkte.
Da jeg aldrig personligt har oplevet et af disse problemer på min dopamin-enhed, har det været svært at forklare, hvordan dette ser ud, eller hvornår det sker, men jeg talte med Fröder for at spørge om, hvad de tror, der kunne være årsagen til, at det kunne få mere at vide om, hvordan de forsøger at løse det.
Fröders svar var indsigtsfuldt for ikke-tekniske mennesker som mig og sikkert mange andre i jailbreak-miljøet og har siden været udgivet til en GitHub-udgaveside for offentligheden at se. Det fulde svar, citeret nedenfor, afslører Fröders forståelse af Spinlock Timeout Panic-problemet:
Her er et forsøg på en mere dybdegående forklaring af problemet, til min bedste nuværende forståelse af det. Husk, at det er baseret på antagelser, som er dybest set umulige at verificere.
Så i et flertrådet system bruges 'låse' til at forhindre to tråde i at forstyrre hinanden. Ved at en tråd kan erhverve en lås, foretage ændringen og låse den op. Mens den er låst, vil en anden tråd, der forsøger at opnå låsen, vente, indtil objektet er blevet låst op igen.
En spinlock er i bund og grund det samme, kun brugt til præstationsrelevante ting, og den største forskel er, at en spinlock kan time-out, hvis noget tager låsen for lang tid, mens en anden tråd forsøger at erhverve låsen. Så når du anskaffer en lås, og objektet allerede er låst, vil det vente et par flueben, og hvis objektet ikke bliver låst op inden for den tidsramme, vil det timeout.
Denne mekanisme i sig selv er ikke problemet, problemet har at gøre med hukommelse sider. Hver hukommelsesside (som beskriver et område på 16 kB RAM) har en spinlock, så der ikke er problemer, når flere processer forsøger at erhverve den samme side på samme tid.
Specifikke sider kan kortlægges i flere processer (f.eks. hvis begge indlæser det samme bibliotek), genbruger de den samme side for at spare hukommelse. Tweaks ønsker at overskrive en sådan hukommelse på en per-proces basis, så de skal først lave en processpecifik kopi af den eksisterende mapping og kortlægge den oven på den, så f.eks. en side kan ændres i én proces, mens der er lagerbeholdning i de andre processer. Problemet ser ud til at opstå specifikt, når der kortlægges oven på en side, der ligger inde i dyld_shared_cachen.
Problemet er nu, at Apple sandsynligvis aldrig har testet denne form for hooking, og når du gør det i mange processer, kan det tilsyneladende forårsage, at den originale side (den af den delte mapping) bliver bladret ud, fordi den ikke bliver brugt aktivt . Udsøgning af en side fjerner i det væsentlige den fra RAM, og når den åbnes igen, vil den blive indlæst igen. På et lagersystem vil dette ikke ske, fordi intet er blevet tilsluttet.
Nu ser hovedårsagen ud til at være noget, der forsøger at side en tidligere udsidet delt/eksekverbar side ind igen, dette udløser et præemptionsproblem, hvor en tråd tager spinlocken, og mens den har det, bliver den foregrebet til en anden kontekst, som også tager samme spinlock (Preemption er i bund og grund en mekanisme, der tillader, at en tråd kan bruges til noget andet, selvom den er optaget i øjeblikket, kode skal eksplicit deaktivere og genaktivere den, hvis der er et stykke kode, der altid skal udføres på én gang) . Så der ser ud til at være én kodesti, som kun påkaldes fra denne særlige adfærd, hvor Apple ikke korrekt deaktiverer præemption, hvilket fører til, at en tråd tager den samme spinlock to gange, hvilket gør det timeout, fordi den gamle kontekst ikke udføres længere og kan ikke låse spinlock op igen.
Med hensyn til at afbøde det, prøvede jeg at rode med spinlock-relaterede variabler for at gøre den tærskel, der skal til for at timeoutet, højere, desværre skruede Apple os over, fordi alt relateret til det er KTRR-beskyttet, som vi ikke har en bypass til. Jeg gætter på, at den korrekte løsning ville være at 'wire down' (nedkobling af en side forhindrer den i at blive paget ud) hver side, der skal tilsluttes, før den overskrives for at sikre, at siden ud aldrig sker, og derfor er kodestien involveret i problemet udløses ikke, jeg har prøvet en masse ting indtil videre, men det ser ud til, at det er direkte umuligt at erhverve sådan en ledning fra brugerområdet, så det skal gøres inde i kernen. Desværre er strukturerne involveret i denne specifikke delte kortlægning, der forårsager problemet, meget indviklede, og jeg har endnu ikke fundet en måde at få det korrekte sideobjekt til at anvende ledningerne til.
Problemet med Spinlock Timeout Panic har eksisteret siden dopamin først blev tilgængeligt og fortsætter med at blive hængende den dag i dag trods mange forsøg for at løse problemet. Når det så er sagt, er det at åbne dialogen for flere mennesker at se og bidrage til det rigtige skridt fremad, da det gør det nemmere for flere hjerner at brainstorme problemet og en mulig løsning.
Fröder forklarer deres næste idé til at forsøge at forpurre problemet i en opfølgende kommentar:
Så det næste trin for at prøve at rette det ville være at finde vm_page-strukturen af en DSC-side i kernehukommelsen, indtil videre er alle mine forsøg på at finde en sådan struktur mislykkedes.
Selvom det ikke har påvirket mig direkte endnu, vil det virkelig være interessant at se, om Fröder er i stand til at løse Spinlock Timeout Panic-problemet. Det ser ud til at være mere udbredt for brugere, der installerer flere jailbreak-tweaks, der kobler C-funktioner. Det kan bare være, at min testenhed ikke har en masse tweaks installeret på den for at udløse problemet, men jeg ved, at der er mange jailbreakere derude, der installerer tonsvis af jailbreak tweaks - mere end jeg nogensinde ville.
Se også: Sådan jailbreaker du A12-A15-enheder, der kører iOS & iPadOS 15.0-15.4.1 med dopamin
Har du nogensinde været ramt af en Spinlock Timeout Panic beskrevet som en lyserød skærm før en pludselig genstart, mens du bruger Dopamine jailbreak? Fortæl os det i kommentarfeltet nedenfor.