Page MenuHomePhabricator

[IR] Define "ptrauth" operand bundle.

Authored by ab on Nov 11 2021, 9:08 AM.



Building on D90868, this introduces a new "ptrauth" operand bundle to be used in call/invoke. At the IR level, it's semantically equivalent to an @llvm.ptrauth.auth followed by an indirect call, but it additionally provides hardening guarantees, by preventing the intermediate raw pointer from being exposed.

This mostly adds the IR definition, verifier checks, and support in a couple of general helper functions. clang IRGen and backend support will come separately.

Note that we'll eventually want to support this bundle in indirectbr as well, for similar reasons. indirectbr currently doesn't allow bundles at all, and the IR data structures need some rejiggering.

Diff Detail

Event Timeline

ab created this revision.Nov 11 2021, 9:08 AM
ab requested review of this revision.Nov 11 2021, 9:08 AM
bruno accepted this revision.Nov 18 2021, 6:41 PM

Given context from further patches in the set, I believe ptrauth operand bundle has been a good way to represent this and works well. LGTM

This revision is now accepted and ready to land.Nov 18 2021, 6:41 PM

I just have 2 bike-sheddy comments on the documentation text.
My comments should not let you delay in getting this committed if they do not make sense to you.


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?


similarly to my other comment "are never attackable" seems a bit strong. Would "are never stored and reloaded to/from memory" be a more exact description of the added guarantee?