[all-commits] [llvm/llvm-project] 7d38c3: [BOLT] Gadget scanner: fix LR to be safe in leaf f...

[Anatoly Trosinenko via All-commits]

  Branch: refs/heads/users/atrosinenko/bolt-gs-lr-in-leaf-nocfg-functions
  Home:   https://github.com/llvm/llvm-project
  Commit: 7d38c3ebb3dd7f67f87b494e2dfe6e6c4ca29787
      https://github.com/llvm/llvm-project/commit/7d38c3ebb3dd7f67f87b494e2dfe6e6c4ca29787
  Author: Anatoly Trosinenko <atrosinenko at accesssoftek.com>
  Date:   2025-05-28 (Wed, 28 May 2025)

  Changed paths:
    M bolt/lib/Passes/PAuthGadgetScanner.cpp
    M bolt/test/binary-analysis/AArch64/gs-pacret-autiasp.s
    M bolt/test/binary-analysis/AArch64/gs-pauth-authentication-oracles.s
    M bolt/test/binary-analysis/AArch64/gs-pauth-debug-output.s
    M bolt/test/binary-analysis/AArch64/gs-pauth-signing-oracles.s

  Log Message:
  -----------
  [BOLT] Gadget scanner: fix LR to be safe in leaf functions without CFG

After a label in a function without CFG information, use a reasonably
pessimistic estimation of register state (assume that any register that
can be clobbered in this function was actually clobbered) instead of the
most pessimistic "all registers are unsafe". This is the same estimation
as used by the dataflow variant of the analysis when the preceding
instruction is not known for sure.

Without this, leaf functions without CFG information are likely to have
false positive reports about non-protected return instructions, as
1) LR is unlikely to be signed and authenticated in a leaf function and
2) LR is likely to be used by a return instruction near the end of the
   function and
3) the register state is likely to be reset at least once during the
   linear scan through the function



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications