4 ms·
No, it must be sign-extended from the top bit of the valid set. Otherwise the address is non-canonical.
by amscanne 6y ago
No, it must be sign-extended from the top bit of the valid set. Otherwise the address is non-canonical.
- xxpor 6y agoThis is true for x86-64, not true for other architectures such as arm64. Apple uses the high bits to cryptographicly sign the pointer value.
- everybodyknows 6y agoFascinating. Does this confer some of the benefits of ECC RAM, for pointer data only — without the hardware cost?
- danielheath 6y agoSome (but I believe the advantage is that it’s much harder to inject valid code from a buffer overflow).
- saagarjha 6y agoPAC is more about CFI than preventing shellcode injection (which is done through codesigning and memory protection, mostly).
- my123 6y agoIt's for a different purpose. (as in mitigate to some extent security bugs) And isn't an Apple feature only but an Arm one. (that is only rolling out on Cortex with Cortex-A78C and A78AE) A paper on it from Qualcomm: https://www.qualcomm.com/media/documents/files/whitepaper-pointer-authentication-on-armv8-3.pdf https://www.qualcomm.com/media/documents/files/whitepaper-po... And there's also MTE which is upcoming.
- haberman 6y agoHmm, it appears that the top byte on arm64 is only ignored if TBI (Top Byte Ignore) is enabled. I don't think pointer signing requires TBI though. Pointer signing uses the PAC instruction to sign a pointer, and the AUT instruction to verify and unpack the signed pointer, but in its signed/packed form it is not a usable pointer. So actual addressable pointers need not support non-canonical addresses.
- saagarjha 6y agoApple runs PAC without TBI enabled, I believe.