================ @@ -255,33 +260,160 @@ signing schema breaks down even more simply: It is important that the signing schema be independently derived at all signing and authentication sites. Preferably, the schema should be hard-coded everywhere it is needed, but at the very least, it must not be derived by -inspecting information stored along with the pointer. +inspecting information stored along with the pointer. See the section on +`Attacks on pointer authentication`_ for more information. + -Language Features +Language features ----------------- -There is currently one main pointer authentication language feature: +There are three levels of the pointer authentication language feature: + +- The language implementation automatically signs and authenticates function + pointers (and certain data pointers) across a variety of standard situations, + including return addresses, function pointers, and C++ virtual functions. The + intent is for all pointers to code in program memory to be signed in some way + and for all branches to code in program text to authenticate those + signatures. + +- The language also provides extensions to override the default rules used by + the language implementation. For example, the ``__ptrauth`` type qualifier + can be used to change how pointers are signed when they are stored in + a particular variable or field; this provides much stronger protection than + is guaranteed by the default rules for C function and data pointers. -- The language provides the ``<ptrauth.h>`` intrinsic interface for manually - signing and authenticating pointers in code. These can be used in +- Finally, the language provides the ``<ptrauth.h>`` intrinsic interface for + manually signing and authenticating pointers in code. These can be used in ---------------- ojhunt wrote:
> > 1. you would use the macros from `ptrauth.h` anytime you have a > > non-standard or complex signing schema - we have to use these macros in > > unwinding as the pc and stack pointers are counter signed. That's an idiom > > that is valuable in other contexts as well - for example, if you have ABI > > constraints that require a type be memcopyable you may want to adopt a > > custom schema where fields get countersigned so that you can ensure the > > overall struct is not compromised/intermingled without incurring the abi > > breakage the address discrimination would cause. > > Ah, thank you! Do you think it's worth mentioning this in the docs? I think it's a reason to assume that people who want a custom schema would come to the docs and find the ptrauth macro section that provides the raw operations. Putting such docs here would basically mean that a person would still have to decide they want a custom schema, then come to the docs, and find the intrinsics - so I don't think it ends up being helpful. Similarly it seems like the docs themselves would be "these intrinsics provide you with the ability to manually sign and auth pointers in case you want to manually sign and auth pointers" > > > 2. GetProcAddress would be expected to return a correctly signed pointer. > > The user does not need to do anything themselves: the linker is trust root, > > and has to ensure that what it does vend are valid and correctly signed. > > Ah, that should probably be explicitly documented. I was thinking you'd have > the ability to do something yourself here, because I'm used to Win32 APIs > like [`EncodePointer` and > `DecodePointer`](https://learn.microsoft.com/en-us/previous-versions/bb432254(v=vs.85)) > where you can manually protect pointers. I've talked to a few people, and they say the in _principle_ the OS could have these vend unsigned pointers, and a dev could assume that those returned pointers would be "trusted" and so start signing them at that point. It does introduce a bunch of hazards though (basically it becomes possible for a developer to accidentally store - or spill - the returned value prior to starting the signed path). But either way it is fundamentally a platform decision, and a platform that is introducing pointer auth will know what they consider their protection path to be, what security guarantees they want (within reason, ptrauth is fundamentally probabilistic), and what changes they can actually make. As a result I'm not super comfortable including such docs in what is fundamentally a clang feature documentation. We could say "a platform that supports dynamic loading or symbol resolution will need to specify the pointer auth semantics of such operations." (and as a result I realize I need to add this info to the apple abi section of the pointer auth docs) https://github.com/llvm/llvm-project/pull/152596 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
