new: uprobe OverrideCall action

[FedeDP]

Description

This PR introduces a new Action for uprobes: OverrideCall. It allows to route the uprobe symbol calls to the specified newSymbol symbol.

uprobes:
- path: "test"
  symbols:
  - "malloc"
  selectors:
  - matchActions:
    - action: OverrideCall
      newSymbol: "malloc_patched"

Shortcomings:

• the new symbol must be binary-compatible with the hooked one! (no check is in place!)
• the new symbol must be already present in the binary
• uprobe only
• only one uprobe hook symbol/addr/offset is supported when using the new action
• kernel support to mess with raw regs is needed
• mixing Override and OverrideCall is unsupported (makes no sense anyway); but the code to support it is there, the mixing only gets gated behind a conditional check

Changelog

new: uprobe OverrideCall action

[netlify]

✅ Deploy Preview for tetragon ready!

Name	Link
🔨 Latest commit	709198c
🔍 Latest deploy log	https://app.netlify.com/projects/tetragon/deploys/6a02fce99edaee0008a5848f
😎 Deploy Preview	https://deploy-preview-4990--tetragon.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[mtardy]

Might be worth chatting with @dwindsor about the "override" API also used from #4817.

[FedeDP]

Thanks @mtardy for the pointer, didn't notice that PR had a new Override sub-action (clearGoString).
Will chat with David for sure!

[dwindsor]

Not sure what this PR is doing but the overall shape of the clearGoString override is:

- matchActions:
 - action: Override
    argIndex: 2
    clearGoString: true

[dwindsor]

Interesting! A few comments.

1. What runtimes are we supporting with this? Seems like symtab would still be necessary to make this work.

2. the new symbol must be already present in the binary

Does this mean a security team needs to pre-compile and seed the binary?

3. Some of the assumptions regarding target function address calculation andPT_LOAD will break down unless it's statically-compiled Go. Offset() in file.go finds the first PT_LOAD segment containing the vaddr and uses this as the base. This assumption won't hold across all runtimes / linkers, for instance when creating shared libraries if multiple PT_LOAD segments are created, a vaddr in one could easily collide with a vaddr in another. If the symbol we're replacing (malloc) is in a different segment than the symbol we're replacing it with (malloc_patched), the replacement works. But if it's in another segment, the RIP calculation will silently fail.

[FedeDP]

What runtimes are we supporting with this? Seems like symtab would still be necessary to make this work.

Yes, exactly. In case the binary is going to be stripped, one can provide directly the Offset.

Does this mean a security team needs to pre-compile and seed the binary?

Yes; this is mostly an initial feature set, of course. We can expand it later!