register normalizeTimeArg processor only when proctree is on

[geyslan]

Close: #4330

1. Explain what the PR does

0b35baa fix(ebpf): register processor conditionally

Register SchedProcessFork processors, including normalizeTimeArg,
only if proctree is enabled.

206e160 fix(ebpf): try to assert only when it is not nil

The normalizeTimeArg function was not checking if the value was nil
before asserting it as an uint64.

This also adds the type to the error message.

2. Explain how to test it

sudo ./dist/tracee -e sched_process_fork
sudo ./dist/tracee --proctree source=both -e sched_process_fork to have related args filled.

3. Other comments

[NDStrahilevitz]

In what case will a time arg be nil?

[geyslan]

In what case will a time arg be nil?

Currently, when not using proctree, see:

sudo ./dist/tracee -e sched_process_fork

17:35:12:005276  1000   IPDL Background  16017   16052   0                sched_process_fork        parent_tid: 16052, ..., **parent_process_start_time: <nil>**, leader_tid: <nil>, leader_ns_tid: <nil>, leader_pid: <nil>, leader_ns_pid: <nil>, leader_start_time: <nil>

sudo ./dist/tracee --proctree source=both -e sched_process_fork

17:37:29:009715  1000   firefox          16017   16017   0                sched_process_fork        parent_tid: 16017, ..., **parent_process_start_time: 1727389186434828788**, leader_tid: 16017, leader_ns_tid: 16017, leader_pid: 16017, leader_ns_pid: 16017, leader_start_time: 1727389260327760332

[NDStrahilevitz]

In what case will a time arg be nil?

Currently, when not using proctree, see:

sudo ./dist/tracee -e sched_process_fork

17:35:12:005276  1000   IPDL Background  16017   16052   0                sched_process_fork        parent_tid: 16052, ..., **parent_process_start_time: <nil>**, leader_tid: <nil>, leader_ns_tid: <nil>, leader_pid: <nil>, leader_ns_pid: <nil>, leader_start_time: <nil>

sudo ./dist/tracee --proctree source=both -e sched_process_fork

17:37:29:009715  1000   firefox          16017   16017   0                sched_process_fork        parent_tid: 16017, ..., **parent_process_start_time: 1727389186434828788**, leader_tid: 16017, leader_ns_tid: 16017, leader_pid: 16017, leader_ns_pid: 16017, leader_start_time: 1727389260327760332

That's odd. Sounds to me like that is the bug.

[geyslan]

If you're not using proctree, it should have been fed by the control plane signal, right?

[NDStrahilevitz]

Ok so these arguments are sort of "metadata" arguments which are submitted on a need basis for the process tree (see here). I then question what merit they have as arguments. Arguments or as want to call it "event data" should reflect user informative data on the event. If this is not such data, that is, it is some sort of "metadata" argument, then that reflects an issue in the event format.
Further, it implies that the processing should be applied conditionally. WDYT?
@yanivagman @itaysk I think we need to take this usecase into account in #2870 (event specific "data" which is relevant for internal logic but not for the user)

[geyslan]

Further, it implies that the processing should be applied conditionally. WDYT?

It is:

tracee/pkg/ebpf/processor.go

Lines 100 to 102 in 1a0065b

	switch t.config.ProcTree.Source {
	case proctree.SourceEvents, proctree.SourceBoth:
	t.RegisterEventProcessor(events.SchedProcessFork, t.procTreeForkProcessor)

[NDStrahilevitz]

@geyslan

The relevant processor is here

tracee/pkg/ebpf/processor.go

Lines 87 to 93 in 1a0065b

	// any later code has access to normalized time arguments.
	t.RegisterEventProcessor(events.SchedProcessFork, t.normalizeTimeArg(
	"start_time",
	"parent_start_time",
	"parent_process_start_time",
	"leader_start_time",
	))

[geyslan]

Nice. This makes sense to me now. So yeah, I believe it should be in the condition below.