Skip to content

tetragon: Add v6.0 bpf objects and related fixes #537

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

Merged
merged 13 commits into from
Nov 17, 2022

Conversation

olsajiri
Copy link
Contributor

With clang 14 the prepend_path loop code does not pass verifier
on v6.x kernels, which can be fixed by using bpf_loop helper.

In order to use bpf_loop helper easily, I'm adding v6.0 version of
bpf objects, so we don't need to detect features and have specific
binary for each.

The v6.0 seems to be the latest stable, I'm not sure it will be longterm,
but with 5.19 EOL the other possibility is 5.15 which does not have
bpf_loop helper.. but I'm open to suggestions in here ;-)

Note I plan to move kprobe_multi objects into v60 in following changes.

Signed-off-by: Jiri Olsa [email protected]

@olsajiri olsajiri force-pushed the v60_objects branch 4 times, most recently from 6ddb772 to 69edec9 Compare November 11, 2022 14:40
@olsajiri olsajiri marked this pull request as ready for review November 11, 2022 15:29
@olsajiri olsajiri requested a review from a team as a code owner November 11, 2022 15:29
@olsajiri olsajiri requested a review from kevsecurity November 11, 2022 15:29
Copy link
Contributor

@kkourt kkourt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Just some small comments from my side.

It would be nice to use bpf_d_path here, but AFAICT we cannot:


static bool bpf_d_path_allowed(const struct bpf_prog *prog)
{
	if (prog->type == BPF_PROG_TYPE_TRACING &&
	    prog->expected_attach_type == BPF_TRACE_ITER)
		return true;

	if (prog->type == BPF_PROG_TYPE_LSM)
		return bpf_lsm_is_sleepable_hook(prog->aux->attach_btf_id);

	return btf_id_set_contains(&btf_allowlist_d_path,
				   prog->aux->attach_btf_id);
}

@olsajiri
Copy link
Contributor Author

Thanks!

Just some small comments from my side.

It would be nice to use bpf_d_path here, but AFAICT we [cannot]

yes, I have plan for that, but first we need to use raw tracepoint with BTF arguments
instead of standard tracepoint.. we can use that in 60 objects

Adding v6.0 version of bpf objects with __V60_BPF_PROG macro
defined. This way we can use/hide v6.0 functionality behind
this macro.

Signed-off-by: Jiri Olsa <[email protected]>
Adding new v6.0 flavor of base sensors. Adding new set of base
sensors with V60 suffix that load *_v60.o based objects.

Signed-off-by: Jiri Olsa <[email protected]>
Adding support to load v6.0 tracing bpf objects (kprobe/tracepoint)
when the v6.0 kernel or newer is detected.

Signed-off-by: Jiri Olsa <[email protected]>
Adding bpf_loop helper definition. It will be used
in folowing changes.

Signed-off-by: Jiri Olsa <[email protected]>
Adding struct cwd_read_data to hold arguments for prepend_path
loop, which will be moved to separate function in following
changes.

Signed-off-by: Jiri Olsa <[email protected]>
Adding dentry to struct cwd_read_data.

Signed-off-by: Jiri Olsa <[email protected]>
Adding vfsmnt to struct cwd_read_data.

Signed-off-by: Jiri Olsa <[email protected]>
Adding mnt to struct cwd_read_data.

Signed-off-by: Jiri Olsa <[email protected]>
Adding bptr/blen to struct cwd_read_data.

Signed-off-by: Jiri Olsa <[email protected]>
Adding resolved to struct cwd_read_data.

Signed-off-by: Jiri Olsa <[email protected]>
Separate the loop in prepend_path so it's handled as:
  - unrolled loop for !__V60_BPF_PROG
  - loop in bpf_loop helper for __V60_BPF_PROG

Signed-off-by: Jiri Olsa <[email protected]>
@olsajiri olsajiri force-pushed the v60_objects branch 2 times, most recently from a4fc8eb to d9915d1 Compare November 16, 2022 14:16
As Kornilios suggested we don't need to read root_dentry/root_mnt
on each iteration. Moving them out of the cwd_read loop function.

Suggested-by: Kornilios Kourtis <[email protected]>
Signed-off-by: Jiri Olsa <[email protected]>
The check is not likely to happen on v6.x kernel.

Signed-off-by: Jiri Olsa <[email protected]>
@kkourt kkourt merged commit a2d6c46 into cilium:main Nov 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants