On Tue, Jun 3, 2025 at 12:29 PM Oliver Hunt wrote:
>>
>>
> > (1) Get the vtable pointer from the object, conveniently always located at [base + 0x00]
> > (2) Dereference the vtable pointer and substract 16 to yield the address of the "distance
> > to most derived" offset.
>
> And this faults immediately because you failed to authenticate the load, and so the load is invalid.
>
> > (3) Add the offset to the address of the sub-object.
>
> You don’t get this far.


I gave up trying to run Qemu in user mode on an x86_64 macOS computer
to run an arm64 macOS executable.

So I'm using the Github Actions runner, 'macos-15', to build and run
my test program.

Here's the code I've got up on GitHub:

    https://github.com/healytpk/polyhandle/blob/main/research_machine_code.cpp

It fails to link. I have identified the compiler option that's causing
the problem, it's "-fptrauth-calls". If I use this compiler option
then I get linker relocation errors about 'std::type_info' as follows:

    ld: relocation at '__ZTV4Frog'+0x0018 is not supported:
r_address=0x48, r_type=11, r_extern=1, r_pcrel=0, r_length=3 in
research_machine_code.o'
    clang++: error: linker command failed with exit code 1 (use -v to
see invocation)

Note that '__ZTV4Frog' is the mangled name for the 'std::type_info'
for the 'Frog' class.

Note that I still get these errors even if I use "-fno-rtti". I've
been searching the web and asking AI but I can't get this code to
compile.

I'm confident that I can figure out getting 'polyhandle' to work on
new Apple computers with pointer authentication, but first I need to
figure out why "-fptrauth-calls" is giving linker errors.

Here's my end game which I think might work:

    A pointer on arm64 is 64-Bit, however on arm64 you can only
address 256 terrabytes of memory. So only 49 of those bits are needed
for a memory address. That leaves 15 bits to play around with. Plus,
since we know that any polymorphic object begins with a vtable
pointer, this means that alignof(any polymorphic class) >= 8. This
means that we can play around also with the lowest 3 bits because
they'll always be zero. So in total we have 18 bits we can manipulate
for our own purposes. The secret number needed to decode the vtable is
only 16 bits. So I'll put that 16-bit secret number + 46 bits memory
address into a " void * ". And I'll still have two bits left over to
play around with.

I'm not absolutely certain that the above paragraph will work -- but
even if it doesn't, I've got two other strategies in mind. I _will_
get 'polyhandle' working on pointer authenticated systems, one way or
another. The above paragraph would be ideal though.