도파민 탈옥 개발자가 파악하기 어려운 Spinlock Timeout Panic 문제에 대해 논의합니다.

도파민 탈옥 개발자가 파악하기 어려운 Spinlock Timeout Panic 문제에 대해 논의합니다.

iOS 및 iPadOS 15.0-15.4.1을 실행하는 A12-A15 장치용 Dopamine 탈옥 도구는 현재 iPhone X보다 최신 장치에서 사용할 수 있는 최신 단일 탈옥 도구입니다 . 그렇긴 하지만 오늘날 탈옥자들 에게 인기 있는 선택이라는 것은 놀라운 일이 아닙니다 .

Lars Fröder는 도파민 탈옥의 Spinlock Timeout Panics에 대해 GitHub 페이지에 트윗했습니다.

그러나 Dopamine을 사용했거나 프로젝트가 시작된 이래로 프로젝트를 따라왔다면 프로젝트 수석 개발자 Lars Fröder(@opa334dev)와 사용자 모두가 Spinlock이라는 특정 단어를 꽤 많이 들었을 것입니다.

실제로 Spinlock Timeout Panic이라고 불리는 Dopamine 탈옥에 영향을 미치는 알려진 문제가 있으며, 이로 인해 사용자의 장치에 분홍색 화면이 표시되고 겉보기에 도발되지 않은 방식으로 재부팅됩니다. 이 문제는 기술적인 용어로 다음과 같이 설명되었습니다.

dyld_shared_cache 실행 가능 페이지 위에 매핑하면 PPL에서 가끔 메모리 페이지의 스핀 잠금에 대한 시간 초과가 발생하여 커널 패닉이 발생하는 극단적인 경우 동작이 발생하는 것으로 보입니다.

후크 C 기능이 더 많이 설치되고 더 많은 프로세스가 주입될수록 이 동작이 더 자주 발생하는 것 같습니다.

이 문제는 연결된 모든 페이지를 연결하여 해결할 수 있는 것으로 보이지만 사용자 공간은 이러한 잠금을 사용할 수 없으며 연결된 비트를 직접 뒤집기 위해 커널 메모리에서 vm_page 개체를 찾는 것이 어려운 것으로 입증되었습니다.

나는 Dopamine 장치에서 이러한 문제 중 하나를 개인적으로 경험한 적이 없기 때문에 이것이 어떻게 나타나는지, 언제 발생하는지 설명하기가 어려웠습니다. 그들은 그것을 해결하려고 노력하고 있습니다.

Fröder의 반응은 나와 같은 기술 지식이 없는 사람들과 탈옥 커뮤니티의 다른 많은 사람들에게 통찰력이 있었으며 이후 대중이 볼 수 있도록 GitHub 문제 페이지에 게시되었습니다 . 아래에 인용된 전체 응답은 Spinlock Timeout Panic 문제에 대한 Fröder의 이해를 보여줍니다.

다음은 문제에 대한 현재 최선의 이해를 바탕으로 문제에 대한 보다 심층적인 설명을 시도한 것입니다. 기본적으로 검증이 불가능한 가정을 기반으로 한다는 점을 명심하세요.

따라서 다중 스레드 시스템에서는 두 스레드가 서로 간섭하는 것을 방지하기 위해 “잠금”이 사용됩니다. 이를 통해 하나의 스레드가 잠금을 획득하고 수정하고 잠금을 해제할 수 있습니다. 잠겨 있는 동안 잠금을 획득하려는 다른 스레드는 개체가 다시 잠금 해제될 때까지 기다립니다.

스핀록은 본질적으로 동일하며 성능 관련 작업에 사용되며 주요 차이점은 다른 스레드가 잠금을 획득하려고 시도하는 동안 잠금이 너무 오래 걸리면 스핀록이 시간 초과될 수 있다는 것입니다. 따라서 잠금을 획득하고 개체가 이미 잠겨 있으면 몇 틱 동안 대기하고 해당 시간 내에 개체가 잠금 해제되지 않으면 시간 초과됩니다.

이 메커니즘 자체는 문제가 아니며 문제는 메모리 페이지와 관련이 있습니다. 모든 메모리 페이지(RAM의 16kB 영역을 나타냄)에는 스핀록이 있으므로 여러 프로세스가 동시에 동일한 페이지를 얻으려고 할 때 문제가 없습니다.

특정 페이지는 여러 프로세스에 매핑될 수 있으며(예: 둘 다 동일한 라이브러리를 로드하는 경우) 메모리를 절약하기 위해 동일한 페이지를 재사용합니다. 조정자는 프로세스별로 이러한 메모리를 덮어쓰려고 하므로 먼저 기존 매핑의 프로세스별 복사본을 만들고 그 위에 매핑해야 합니다. 예를 들어 재고를 유지하면서 한 프로세스에서 한 페이지를 수정할 수 있습니다. 다른 프로세스에서는. 이 문제는 특히 dyld_shared_cache 내부에 있는 페이지 위에 매핑할 때 발생하는 것 같습니다.

문제는 이제 Apple이 이런 종류의 후킹을 테스트한 적이 없으며 분명히 많은 프로세스에서 이를 수행할 때 원본 페이지(공유 매핑 중 하나)가 적극적으로 사용되지 않기 때문에 페이지 아웃될 수 있다는 것입니다. . 페이지를 페이지 아웃하면 기본적으로 RAM에서 해당 페이지가 제거되며 다시 액세스하면 다시 로드됩니다. 스톡 시스템에서는 연결된 것이 없기 때문에 이런 일이 발생하지 않습니다.

이제 근본 원인은 이전에 페이지 아웃된 공유/실행 가능 페이지를 다시 페이지로 넣으려고 시도하는 것으로 보입니다. 이는 하나의 스레드가 스핀록을 가져오는 선점 문제를 유발하고 스핀록이 있는 동안 다른 컨텍스트로 선점됩니다. 동일한 스핀록(선점은 본질적으로 하나의 스레드가 현재 사용 중이더라도 다른 스레드에 사용될 수 있도록 허용하는 메커니즘입니다. 항상 한 번에 실행되어야 하는 코드 조각이 있는 경우 코드는 이를 명시적으로 비활성화했다가 다시 활성화해야 합니다) . 따라서 Apple이 선점을 올바르게 비활성화하지 않는 이 특정 동작에서만 호출되는 하나의 코드 경로가 있는 것 같습니다. 이로 인해 하나의 스레드가 동일한 스핀록을 두 번 사용하게 되어 이전 컨텍스트가 더 이상 실행되지 않고 시간 초과가 발생합니다. 스핀락을 다시 잠금 해제할 수 없습니다.

Spinlock Timeout Panic 문제는 Dopamine이 처음 사용 가능해진 이후부터 발생했으며 이 문제를 해결하려는 많은 시도에도 불구하고 오늘날까지 계속 남아 있습니다 . 하지만 더 많은 사람들이 보고 기여할 수 있도록 대화를 여는 것이 올바른 진전입니다. 더 많은 사람들이 문제와 가능한 해결책을 브레인스토밍하는 것이 더 쉬워지기 때문입니다.

Fröder는 후속 의견에서 문제를 방지하기 위한 다음 아이디어를 설명합니다.

따라서 이 문제를 해결하기 위한 다음 단계는 커널 메모리에서 DSC 페이지의 vm_page 구조를 찾는 것입니다. 지금까지 그러한 구조를 찾으려는 모든 시도는 실패했습니다.

아직 나에게 직접적인 영향을 미치지는 않았지만 Fröder가 Spinlock Timeout Panic 문제를 해결할 수 있는지 보는 것은 정말 흥미로울 것입니다. C 기능을 연결하는 탈옥 조정을 더 많이 설치하는 사용자에게 더 널리 퍼진 것 같습니다. 내 테스트 장치에 문제를 유발하는 조정 기능이 많이 설치되어 있지 않을 수도 있지만, 저보다 더 많은 탈옥 조정 기능을 설치하는 탈옥자가 많다는 것을 알고 있습니다.

참고 항목: Dopamine을 사용하여 iOS 및 iPadOS 15.0-15.4.1을 실행하는 A12-A15 장치를 탈옥하는 방법

Dopamine 탈옥을 사용하는 동안 갑자기 재부팅하기 전에 분홍색 화면으로 설명되는 Spinlock Timeout Panic의 영향을 받은 적이 있습니까? 아래 댓글 섹션을 통해 알려주세요.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다