[TUHS] PG3 or Gen3.0?

[Clem Cole via TUHS]

On Fri, May 8, 2026 at 11:51 AM Cameron Míċeál Tyre via TUHS <tuhs at tuhs.org>
wrote:

> I've come to realize, only recently, that Apple moving from Intel's x86-64
> architecture to their own take on AArch64/ARM64 might help them streamline
> design, development and production but it's a royal pain in the derriere
> for many other reasons. Quite a few packages I've tried to install over the
> last year have turned out to be for Intel x86-64 Macs and nothing later.
>
> Regarding your issue, below, you can disable SIP, or at least, you used to
> be able to do so.
>
Yes, but it does not change the arm64e / arm64 binary issue on macOS; a
binary stored in a macho file marked as arm64e includes Pointer
Authentication Codes (PAC).

PAC is an Apple security feature designed to prevent memory corruption and
code-injection attacks.  The two binary formats differ in instruction set
features and how the OS handles them:

   - Security (PAC): arm64e utilizes ARMv8.3-A instructions to
   cryptographically sign and verify pointers (like return addresses and
   function pointers) before use. If a pointer is tampered with by malware,
   the authentication fails, and the program crashes safely instead of
   executing malicious code. Standard arm64 binaries do not use these
   instructions.
   - ABI Stability: The arm64e Application Binary Interface (ABI) is
   considered unstable and "private" by Apple. Apple uses it for all its
   own system software—such as the kernel and system libraries—because they
   can recompile the entire OS if the ABI changes.
   - Third-Party Support: Most third-party apps are distributed as arm64.
   Apple generally restricts the distribution of arm64e binaries in the App
   Store because the changing ABI would cause them to break on future macOS
   updates.
   - Binary Execution:
      - arm64 binaries run on all Apple Silicon Macs.
      - arm64e binaries only run on processors that support PAC (A12 chips
      or M1 and newer) and usually require special developer "preview" flags to
      run if they aren't signed by Apple.
   - Interoperability: An arm64 executable can call arm64e libraries, but
   an arm64e executable cannot call standard arm64 libraries for security
   reasons, as doing so would bypass the pointer protections.

This last point is what bites brew in the backside, with dynamic libraries
[which is how I ran into the problem earlier this week].