================ @@ -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. ---------------- ojhunt wrote:
It's not just paths leading to code pointers - it can be (and in practice is) used to protect many different kinds of program state (an OS might choose to use ptrauth to protect a process's user id from modification for example), or access permissions, etc. Essentially any pointer that can be used to gain more privileges or control than is intended in the normal course of operation can be considered for protection. > With there being quite a bit of literature about how attackers can build > exploits by overwriting (only?) these data pointers with techniques such as > [COOP](https://www.computer.org/csdl/proceedings-article/sp/2015/6949a745/17D45VsBU41) > (overwriting v-table pointers) and > [CFOP](https://www.usenix.org/conference/usenixsecurity25/presentation/bajo) > (over-writing data pointers to coroutine data structures), that's the > motivation to also protect that class of data pointers (but not other classes > of data pointers)? Time and ABI visibility - the nature of lambdas and coroutines means that their internal representation is tied to a single TU so we have much more freedom over what we can change and improve over time. Things like vtable pointers, function pointers, objc's various meta data pointers, etc are exposed as platform ABI so we've tried to get as much as possible protected before reaching the point where we can no longer change the ABI. Essentially anything exposed as platform ABI is fixed - we've been talking to the linux ptrauth folk to help them understand which places are choices made out of necessity/compatibility with real code, and which are just the result of us being ABI restricted. 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
