And I also remember attending a DEF CON (or a similar conference) talking about how the keys used to sign shared library code is shared across all processes (including unsandboxed, privileged processes) and depending on your perspective, it could be a vulnerability.

Intel added SHA with Goldmont, for smaller laptops. But it's only SHA1 and SHA2, which are already outdated. Good enough for ptrauth though.

(Rebuttal: Some languages have fat pointers or maybe some architectures support 32-bit binaries.. I think having the key tied to the payload size would address the theoretical weakness there? In practice signed pointers are already fat pointers and the contents of fat pointers are not actually addresses in the first place, and neither are supported in the current implementation.)

But... Combining with HMAC isn’t exactly a seal of approval. HMAC with MD5 is still considered secure because even if you made a hash collision you didn’t have the key.

And yes, SHA3 would be overkill. Most people don’t understand the mechanics of hashing let alone the new keying that SHA3 brings.

https://blake2.net/

Blake2 is about a factor of 1000 slower. Secure hashes are not really applicable for pointer hashing (i.e. 48bit). Some need 16byte alignment (but you can use a stack word for that), some need excessive padding. Here the padding will kill you.