ojhunt wrote: > > > * Fix personality pointer authentication on non-Apple targets: > > > [[runtimes][PAC] Harden unwinding when possible #143230 > > > (comment)](https://github.com/llvm/llvm-project/pull/143230#discussion_r2318636296) > > > > > > I'm not sure what's going on in this diff as it does not appear related to > > changes in this PR? Is it just a general issue that already exists? > > @ojhunt Well, I'd rather say that it's not an issue that already exists, it's > just missing functionality - libunwind does not support ptrauth-hardened > personality pointer, and this is true for both signed personality pointer on > Apple and Linux. We just have different signing schemes, and the signing > scheme on Linux is defined in this PR: #119361 > > If you prefer not to include support for signed personality on Linux, I would > be happy to submit support for that as a follow-up PR as soon as this one is > merged (since logic for Linux is similar to logic for Apple, we just have > different discriminators). But, if we take this approach, let's at least add > a TODO note mentioning that signed personality now only works for Apple's > arm64e, and support for Linux will be implemented in future. > > Probably, we can use smth like this: > > ``` > #if __has_feature(ptrauth_calls) // as discussed in discord, let's replace > that with some macro for calls+returns > if (personality) { > #if __APPLE__ > const auto discriminator = ptrauth_blend_discriminator( > &cieInfo->personality, > __ptrauth_unwind_cie_info_personality_disc); > void *signedPtr = ptrauth_auth_and_resign( > (void *)personality, ptrauth_key_function_pointer, resultAddr, > ptrauth_key_function_pointer, discriminator); > personality = (pint_t)signedPtr; > #else > #error "Signed personality function pointer is not supported for non-Apple > targets" > // TODO: Implement support for Linux. The signing scheme of personality > pointer > // differ for Linux and Apple targets. For Linux targets, the signing scheme > is > // defined in https://github.com/llvm/llvm-project/pull/119361 > #endif > } > #endif > ``` > > Which approach do you prefer? Is it applying the suggestion from commit > [e2f8b9d](https://github.com/llvm/llvm-project/commit/e2f8b9d3859eff96442ce04662aefb40debbef3f) > or postponing the Linux support and using the code snippet like above? > > I'm OK with both, just please let me know which is more comfortable for you.
I _think_ doing it as a follow up makes sense: it's not a matter of me not wanting to do this for linux, it's that I cannot test it at all. Doing it as a follow up would also give you the constants block to put the definition rather than having it just slotted in the code. I've found moving to the constant blocks to be incredibly useful for being able to see where/how they cross ABI boundaries. https://github.com/llvm/llvm-project/pull/143230 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
