Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression in process info #3949

Closed
oshaked1 opened this issue Apr 3, 2024 · 1 comment · Fixed by #4027
Closed

Regression in process info #3949

oshaked1 opened this issue Apr 3, 2024 · 1 comment · Fixed by #4027
Assignees
Labels
Milestone

Comments

@oshaked1
Copy link
Contributor

oshaked1 commented Apr 3, 2024

Description

A recent optimization effort (f806cb4) moved some parts of the program data initialization to the event submission stage. This results in the information that is used to construct pcap file names to be missing (the process name portion of the pcap file is empty).

I also noticed that (somewhat expectedly), using process info inside a bpf program results in incorrect data. Some bpf programs may rely on this data which will result in unexpected behavior.

There may be more side effects for this change, anywhere that process info is used and isn't in a regular event submitted to user space.

Output of tracee version:

Commit f806cb4

@yanivagman
Copy link
Collaborator

yanivagman commented Apr 3, 2024

A recent optimization effort (f806cb4) moved some parts of the program data initialization to the event submission stage. This results in the information that is used to construct pcap file names to be missing (the process name portion of the pcap file is empty).

The commit was intended to update all instances where a particular field was necessary for a program but left uninitialized. However, network events were inadvertently omitted, as they involve duplicating the entire event context within a different kprobe (__cgroup_bpf_run_filter_skb).

I also noticed that (somewhat expectedly), using process info inside a bpf program results in incorrect data. Some bpf programs may rely on this data which will result in unexpected behavior.

There may be more side effects for this change, anywhere that process info is used and isn't in a regular event submitted to user space.

This is the intended behavior. We don't want to intialize any field if in general it is not required by all (or most) bpf programs. If a specific program needs a certain field - it is the program responsibility to initialize it.

Adding the following line to where we save the network event task context should fix the problem:
init_task_context(&p->event->context.task, p->event->task, p->config->options);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants