[PATCH] D113685: [IR] Define "ptrauth" operand bundle.

[Ahmed Bougacha via Phabricator via llvm-commits]

ab marked 2 inline comments as done.
ab added a comment.

Thanks!

I committed a modified description, happy to make more changes:

> However, that exposes the intermediate, unauthenticated pointer, e.g., if it
> gets spilled to the stack.  An attacker can then overwrite the pointer in
> memory, negating the security benefit provided by pointer authentication.
> To prevent that, the ``ptrauth`` operand bundle may be used: it guarantees that
> the intermediate call target is kept in a register and never stored to memory.
> This hardening benefit is similar to that provided by
> [``llvm.ptrauth.resign``](#llvm-ptrauth-resign)).





================
Comment at: llvm/docs/PointerAuth.md:234-235
+[``llvm.ptrauth.resign``](#llvm-ptrauth-resign)).  To prevent that, the
+``ptrauth`` operand bundle may be used: it guarantees that the intermediate
+call target is never attackable (e.g., by being spilled to memory).
+
----------------
kristof.beyls wrote:
> If you allow me to bikeshed on this sentence: "guaranteeing an intermediate call target is never attackable" seems like a very bold claim to me.
> I wonder if it would (a) be better, and (b) be possible to more concretely define exactly what is guaranteed in more detail.
> Is what is currently guaranteed "it guarantees that the intermediate call target is kept in a register and never stored to memory, e.g. by being spilled"?
> If we want to relate this guarantee to reduced attackability, a sentence could be added saying something like "Not storing and reloading the unauthenticated pointer to/from memory removes an attack surface where an attacker would overwrite the unauthenticated pointer in memory".
> 
> I'm assuming that no other guarantees are implemented?
> If in the future it becomes clear that more guarantees need to be implemented, the documentation here can be extended to list further guarantees?
That's fair, I reworded it based on your comment, to specifically mention the main hardening measure: preventing spills.

But for context: there is indeed more hardening provided here: for all the combined "hardened" ptrauth operations we have, we use only specific registers for "critical" values (e.g., the unauthenticated pointer result of the `auth` here), and the darwin kernel provides additional runtime guarantees on these registers (so that they aren't corruptible even across context switches, etc.)
Another layer is the trapping behavior on auth failures: for several of these operations (including these calls) we rely on the hardware checks, but when we can't, we have the software check/trap sequence, so that these can't be bruteforced.

Either way, that belongs somewhere else in the document, given that it's a property common to most of these operations.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113685/new/

https://reviews.llvm.org/D113685