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

Q/BUG: investigate use of task_pid_nr(...) vs task_tgid_nr(...) #126

Open
pcmoore opened this issue Oct 8, 2020 · 3 comments
Open

Q/BUG: investigate use of task_pid_nr(...) vs task_tgid_nr(...) #126

pcmoore opened this issue Oct 8, 2020 · 3 comments

Comments

@pcmoore
Copy link
Contributor

pcmoore commented Oct 8, 2020

Most of the kernel audit code uses the TGID, or task group ID, in place of the actual PID as most users care more about the processes than threads. However there are a few places in the code where task_pid_nr(...) is used and we might want to change that. This issue is for the investigation of these call sites and any fixes that may be needed.

@pcmoore
Copy link
Contributor Author

pcmoore commented Oct 8, 2020

For example, here is Linus' tree from October 7, 2020:

% grep "task_pid_nr" kernel/audit*.c
kernel/audit.c:                  task_pid_nr(current),
kernel/auditfilter.c:                           pid = task_pid_nr(current);
kernel/auditsc.c:       audit_log_format(ab, " pid=%u", task_pid_nr(current));

@rgbriggs
Copy link
Contributor

rgbriggs commented Oct 8, 2020 via email

pcmoore pushed a commit that referenced this issue Jan 22, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  #119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  #120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  #121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  #122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  #123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  #124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  #125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  #126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  #127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  #128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  #129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  #130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  #486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
pcmoore pushed a commit that referenced this issue Aug 28, 2024
In a few audit records, PIDs were being recorded with task_pid_nr()
instead of task_tgid_nr().

$ grep "task_pid_nr" kernel/audit*.c
audit.c:       task_pid_nr(current),
auditfilter.c: pid = task_pid_nr(current);
auditsc.c:     audit_log_format(ab, " pid=%u", task_pid_nr(current));

For single-thread applications, the process id (pid) and the thread
group id (tgid) are the same. However, on multi-thread applications,
task_pid_nr() returns the current thread id (user-space's TID), while
task_tgid_nr() returns the main thread id (user-space's PID). Since
the users are more interested in the process id (pid), rather than the
thread id (tid), this patch converts these callers to the correct method.

Link: #126

Reviewed-by: Richard Guy Briggs <[email protected]>
Signed-off-by: Ricardo Robaina <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
@rprobaina
Copy link

@pcmoore, I believe this issue can be closed since 61c60977926e ("audit: use task_tgid_nr() instead of task_pid_nr()") has already been merged mainline.

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

3 participants