[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 6/7] tcg: implement JIT for iOS and Apple Silicon

From: Joelle van Dyne
Subject: Re: [PATCH v3 6/7] tcg: implement JIT for iOS and Apple Silicon
Date: Wed, 28 Oct 2020 18:04:56 -0700

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.


On Wed, Oct 28, 2020 at 4:54 AM Stefan Hajnoczi <stefanha@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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]