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

Fix/create ebpf/userland types #4551

Open
geyslan opened this issue Jan 23, 2025 · 0 comments
Open

Fix/create ebpf/userland types #4551

geyslan opened this issue Jan 23, 2025 · 0 comments

Comments

@geyslan
Copy link
Member

geyslan commented Jan 23, 2025

Description

While working on the proc package, I've encountered an issue again regarding the appropriate types to use for specific fields across Tracee (both in BPF and userspace).

To summarize, focusing on the pid field. In BPF, we retrieve it using bpf_get_current_pid_tgid:
https://elixir.bootlin.com/linux/v6.12.6/source/kernel/bpf/helpers.c#L222

We typically extract pid and tgid as u32 each, which is a misconception induced by the helper function.

In reality, both are defined as pid_t:
https://elixir.bootlin.com/linux/v6.12.6/source/include/linux/sched.h#L1018

pid_t is, in turn, defined as __kernel_pid_t:
https://elixir.bootlin.com/linux/v6.12.6/source/include/linux/types.h#L27

which is an int or s32:
https://elixir.bootlin.com/linux/v6.12.6/source/include/uapi/asm-generic/posix_types.h#L28.

This means we've been treating them as unsigned when they should be signed, or as int in Go which has an unnecessary int64 footprint. Beyond interpreting values incorrectly, this also leads to unnecessary conversions throughout the code.

The kernel itself makes use of pid_t as -1:

https://elixir.bootlin.com/linux/v6.12.6/source/kernel/exit.c#L1832
https://elixir.bootlin.com/linux/v6.12.6/source/kernel/pid_namespace.c#L222
https://elixir.bootlin.com/linux/v6.12.6/source/kernel/trace/trace_functions_graph.c#L1333
...

Additional details

Related:

#4504
#3690
#4484 (comment)
#4353

@geyslan geyslan added this to the v0.24.0 milestone Jan 23, 2025
@geyslan geyslan self-assigned this Jan 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant