atrosinenko wrote: I tried to figure out what is the difference between `-mbranch-protection=pac-ret` and `-fptrauth-returns` in the mainline Clang/LLVM. Though, I'm not very familiar with all that option marshalling machinery in Clang, so this included significant amount of grepping.
## Clang There are several options that can be considered entry points on the Clang driver and/or `clang -cc1` sides. There is a pair of `f`-options (`-fptrauth-returns` and `-fno-ptrauth-returns`) as well as three `m`-options: `-msign-return-address=none|all|non-leaf`, `-msign-return-address-key=a_key|b_key`, `-mbranch-protection=<string>` (there is also `-mbranch-protection-pauth-lr` option, but let's consider it out of scope for now). As far as I know, there is significant amount of duplication between `-f...` and `-m...` options w.r.t. pac-ret hardening for hystorical reasons. ### `-fptrauth-returns` Considering the `f`-options, I started with searching for `f(no[_-])?ptrauth[_-]returns` under `/clang/`, excluding `/clang/test/`. This shown me testing for conflicts with `m`-options in `CollectARMPACBTIOptions()`, some amount of hand-written marshalling code and the related field of the `LangOptions` structure: `PointerAuthReturns`. By the way, the tablegen definition itself was not found because it has the form `defm ptrauth_returns : OptInCC1FFlag<"ptrauth-returns", "...">`). Then, by searching for "PointerAuthReturns", one can find `ptrauth_returns` feature (to be exposed via `__has_feature`), `PAuthABIVersion` module flag, more cross-checking with `m`-options in `AArch64TargetInfo::validateBranchProtection()` and `PointerAuthOptions::ReturnAddresses` field. Finally, searching for `ReturnAddresses` reveals setting `"ptrauth-returns"` function attribute. Searching for `ptrauth-returns` under `/clang/` does not add anything new except for the original `defm ptrauth_returns : ...` definition. ### `m`-options Searching for "msign[_-]return[_-]address|mbranch[_-]protection", again, shows testing against `f`-options and some amount of marshalling. Unlike `-fptrauth-returns`, `m`-options are used to choose the multilib variant to use. Finally, `SignReturnAddressScope` and `SignReturnAddressKey` fields of `LangOptions` and corresponding accessor functions can be found. Searching for "SignReturnAddress" (this includes `get*()` and `set*()` accessors, as well as functions like `hasSignReturnAddress()`) yields defining `__ARM_FEATURE_PAC_DEFAULT` macro, more parsing of string representations of branch-protection modes, and two other related symbols: `SignReturnAddr` and `SignKey` fields of `BranchProtectionInfo`. Furthermore, "sign-return-address", "sign-return-address-all" and "sign-return-address-with-bkey" module attributes are set as well as "sign-return-address" and "sign-return-address-key" function attributes. ## LLVM Considering the codegen performed by LLVM backend, grepping for "sign-return-address|ptrauth-returns" suggests that `-fptrauth-returns` can be considered as `-msign-return-address=non-leaf -msign-return-address-key=b_key` (see `GetSignReturnAddress` and `ShouldSignWithBKey` functions in AArch64MachineFunctionInfo.cpp), though there can be minor differences such as different default checking mode for authenticated LR when performing tail calls and emission of some file-level meta-information by AArch64AsmPrinter. 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
