Will fix the typo in the commit message. Re: "reverse engineered functions", Apple does not provide any documentation on their extensions to ARM architecture. APRR is one such proprietary feature that is controlled by MRS/MSR writes to an undocumented system register. We reverse engineered the functionality by tracing how libsystem_pthread.dylib works and replicating the MRS/MSR calls.
More details: https://siguza.github.io/APRR/ Legally, I don't think this is any different from reverse engineering some hardware interface to write a Linux driver but IANAL. -j On Wed, Oct 28, 2020 at 4:54 AM Stefan Hajnoczi <stefa...@redhat.com> wrote: > > On Tue, Oct 27, 2020 at 08:07:00PM -0700, Joelle van Dyne wrote: > > On iOS, we cannot allocate RWX pages without special entitlements. As a > > workaround, we can allocate a RX region and then mirror map it to a separate > > RX region. Then we can write to one region and execute from the other one. > > "separate RW region"? The sentence doesn't seem to make sense if both > regions are RX. > > > > > When entitlements are available (macOS or jailbroken iOS), a hardware > > feature called APRR exists on newer Apple Silicon that can cheaply mark JIT > > pages as either RX or RW. Reverse engineered functions from > > libsystem_pthread.dylib are implemented to handle this. > > What does "Reverse engineered functions" mean? We cannot accept code > into QEMU that is a potential liability if Apple could claim it has been > copied, derived, etc without permission. If libsystem_pthread.dylib is > open source, especially under a permissive license, then it's probably > okay. > > Can you clarify?
