[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

[Kristof Beyls via Phabricator via cfe-commits]

kristof.beyls added inline comments.


================
Comment at: clang/lib/Headers/ptrauth.h:19-37
+  /* A process-independent key which can be used to sign code pointers.
+     Signing and authenticating with this key is a no-op in processes
+     which disable ABI pointer authentication. */
+  ptrauth_key_process_independent_code = ptrauth_key_asia,
+
+  /* A process-specific key which can be used to sign code pointers.
+     Signing and authenticating with this key is enforced even in processes
----------------
rjmccall wrote:
> kristof.beyls wrote:
> > I think, but am not sure, that the decision of which keys are process independent and which ones are process-dependent is a software platform choice?
> > If so, maybe ptrauth_key_process_{in,}dependent_* should only get defined conditionally?
> > I'm not sure if any decisions have been taken already for e.g. linux, Android, other platforms.
> > If not, maybe this block of code should be surrounded by an ifdef that is enabled only when targeting Darwin?
> Yes, in retrospect it was a bad idea to define these particular generic names.  I believe Apple platforms no longer have "process-independent" keys.  It should really just be (1) the concrete keys, (2) recommended default keys for code and data pointers, and then (3) the specific keys used in specific schemas.  Beyond that, if people want a specific different key for some purpose, they should ask for it.
> 
> Unfortunately, there's already a fair amount of code using these names.  We could deprecate the old names and point people towards the new names, though.
Thanks for those background insights!
I was thinking that maybe the keys that should be deprecated could be enabled only when targeting Apple platforms? I'm assuming here that most existing code using these only target Apple platforms; so making them available only when targeting Apple platforms could help with not letting the use of them spread further without impacting existing code much?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112941