================ @@ -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. ---------------- kbeyls wrote:
Right, that makes sense to me. I'm wondering if it there would be a relatively simple description of the kind of data pointers that are signed, or that are considered to get signed in the future? What are the unifying characteristics of the data pointers in "v-table pointers", "lambdas", "coroutines"? I'm not familiar enough with objc to understand what the data pointers are that are considered in those cases. Would all of these be data-pointers that point to blocks of code pointers. Or in other words, all be data pointers that get dereferenced to implement some form of indirect control flow? 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)? 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
