Comment by ComputerGuru | Hacker News Reader

Comment by ComputerGuru | Hacker News Reader

I’m guessing this was developed by or at the behest of Apple and ARM, based off the supported hardware and languages? Are any versions of the iOS or macOS kernel (or even user lands) utilizing this “across the board” now? I’d read papers and theory on strong pointer authentication to mitigate control flow attacks a very long time ago but I did not realize this was now “mainstream” in a consumer compiler (with support for multiple C-like languages to boot!); but it certainly is a tough sell without hardware support, both for security and (perceived) performance benefits. (I say perceived because it turns out that a lot of runtime safety checks are actually virtually undetectable as they are perfect fits for speculative execution and branch prediction, and very easily guessable with high success rates, as demonstrated by the rust benchmarks with and without runtime safety checks enabled having such close performance on modern x86_64 architectures.)

ARMv8.3 shipped with the instructions needed for this implementation of signed pointers in 2016, and presumably Apple played a good role in contribution this feature to the Clang codebase as no other hardware-accelerate authentication scheme is supported, per the document. I wonder if there are any plans to bring this to the desktop, by either of Intel or AMD. AMD is now in a position to actually develop new extensions rather than largely playing catch-up to Intel’s extensions (in recent years). (Then again, AMD remains the only one to really offer hardware acceleration for SHA [0], and that doesn’t seem to have really motivated developers to take advantage of that code.)

[0]: https://neosmart.net/blog/2017/will-amds-ryzen-finally-bring...

iOS since at least 12 has been using it. Here's a blog post by Project Zero describing it: https://googleprojectzero.blogspot.com/2019/02/examining-poi...

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.

It’s been in the compiler for over a year to support the A12 chip, which shipped with pointer authentication.

> AMD remains the only one to really offer hardware acceleration for SHA

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

SHA-2 isn't outdated if used correctly (e.g. combine with HMAC if length extension attacks are a threat to your protocol). SHA-3 is the "break glass in case of emergency" hash.

Doesn't even need HMAC to break length extension. You can just truncate the result ("SHA-512/256"), or use SHA_d(x) = SHA(SHA(x)) or SHA(0^B || SHA(x)). (Although SHA_d starts to look a lot like HMAC.)

Absolutely but it’s all besides the point for this particular application, anyway. If you fix the pointer size (e.g. payload (i.e. both the secure and raw pointers) must be 64 bits, no less, no more) then length extension is a non-issue.

(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.)

You are right, SHA2 is fine still, mostly.

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.

AMD offers it across the board on models since Zen 1, which is probably what the article has in mind. It's nice that Intel offers it as an accelerator on their low-end parts, but ideally they would ship the support across the product range.

Right. Pointer authentication depends on it not being easy to forge a signature given the desired pointer. Given that there's a secret key included in the signature, the requirements on the hash function aren't really very strong. Signatures just need to not leak information about the key that could be used to predict other signatures.

If you care about speed and are concerned about sha1/2 vulnerabilities, maybe take a look at blake2? Faster than sha1, probably a similar level of security as sha3 (it is a redesign of a finalist for sha3). It's also the default for nacl/sodium.

https://blake2.net/

Nope. ptrauth needs a good hash in Hardware. There's only crc32c, aes, sha1 (-160) and sha256 (i.e. sha2-256). Of these crc32c is entirely insecure, aes not applicable, so we are left with AMD, Intel laptops (Goldmont), armv8 and Power8. For sure we don't care about any SHA vulnerabilities here, only about speed.

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.

SHA3 is designed to be quite fast in hardware, there just isn't much hardware that accelerates it yet. Blake2 is faster in software, but that software is (as you note) much slower than SHA2's hardware implementations. So for existing systems SHA2 is the best option. Eventually SHA3 will probably be widespread and SHAKE128 with appropriately chosen output size will be the best choice.

SHA2 is by far not the best option for ptrauth. The best option is HW and API dependant. There are dozens of better options. I recently included most secure hashes with tons of variants into https://github.com/rurban/smhasher/blob/master/README.md#smh... SHA3 would be atrocious. Something like fletcher2 or wyhash seem to be best.

Reply on news.ycombinator.com