WIP: Add support for attaching uprobes and uretprobes to offsets #1419
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1419 +/- ##
==========================================
+ Coverage 72.44% 80.84% +8.39%
==========================================
Files 145 146 +1
Lines 14916 15045 +129
==========================================
+ Hits 10806 12163 +1357
+ Misses 3395 2282 -1113
+ Partials 715 600 -115
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
rafaelroquetto
force-pushed
the
newretprobes2
branch
from
901ae57
to
ac7a5c4
Compare
rafaelroquetto
force-pushed
the
newretprobes2
branch
from
ac7a5c4
to
e5db1f8
Compare
rafaelroquetto
force-pushed
the
newretprobes2
branch
from
e5db1f8
to
16741a5
Compare
rafaelroquetto
force-pushed
the
newretprobes2
branch
from
720fc67
to
bf7c80d
Compare
| return nil | ||
| } | ||
|
|
||
| func (p *Tracer) UProbes() map[string]map[string]ebpfcommon.FunctionPrograms { | ||
| return map[string]map[string]ebpfcommon.FunctionPrograms{ | ||
| func (p *Tracer) UProbes() map[string]map[string][]*ebpfcommon.ProbeDesc { |
There was a problem hiding this comment.
OK, cool, so this was somewhere I thought we needed to go, having an array of probes on a single function when we need to deal with recompilation. Is this why you allow for this now, or there's another reason?
There was a problem hiding this comment.
Actually the reason was to normalise the code between GoProbes() and UProbes() - now they both return maps whose values are map[string][]*ebpfcommon.ProbeDesc, which enables the code to handle them to be generic in instrumenter.go (in particular, the instrumentProbes() function).
| @@ -357,64 +419,44 @@ func (p *Tracer) SockMsgs() []ebpfcommon.SockMsg { return nil } | |||
|
|
|||
| func (p *Tracer) SockOps() []ebpfcommon.SockOps { return nil } | |||
|
|
|||
| func (p *Tracer) RecordInstrumentedLib(id uint64) { | |||
| func (p *Tracer) RecordInstrumentedLib(id uint64, closers []io.Closer) { | |||
There was a problem hiding this comment.
Nice, I really like these splits.
In its core, this PR adds support for attaching ebf programs to (start and return) offsets, in the same fashion done for "goprobes". The motivation is also the same: uretprobes attachments can be unreliable in contexts where the target process stack changes. In such scenarios, attaching uretprobes may cause the target process to crash.
Under the hood, we scan the target binary for the offsets of the symbols we want to attach to: the start offset, and the offset of every
RETinstruction present in that function. This approach is not flawless, and will fail if the the function/symbol in question does not posses anyRETinstruction due to compiler optimisations (see here for an example).Due to the requirement of handling uprobe offsets, codewise the handling of uprobes and goprobes becomes less distinct. The ultimate goal would be to merge their corresponding code and remove considerable code duplication. A central piece for this is the repurposing of
ebpfcommon.FuncProgramsinto a more comprehensive data structure that carries the entire context (relevant to our use cases) of ebpf attachments: apart from the start and end programs, it now features the symbol name and the offsets. This also enables us to ditch a few maps that were being used for this purpose, and simplifies the code considerably.TODO
ebpfcommon.FunctionProgramsto a more appropriate termebpfcommon.FunctionProgramsinstrumenter.go