BPF List
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Dave Tucker <dave@dtucker.co.uk>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	John Fastabend <john.fastabend@gmail.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>, KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>, Yafang Shao <laoar.shao@gmail.com>
Subject: Re: [PATCH bpf-next v2 1/1] bpf: Include pid, uid and comm in audit output
Date: Fri, 15 Dec 2023 09:02:02 -0800	[thread overview]
Message-ID: <3636f52d-f343-45e5-88c6-3c7e28e87a45@linux.dev> (raw)
In-Reply-To: <c61810a0-4b62-415f-abb7-45868fc91d16@linux.dev>


On 12/15/23 8:53 AM, Yonghong Song wrote:
>
> On 12/15/23 8:38 AM, Dave Tucker wrote:
>>
>>> On 15 Dec 2023, at 15:24, Yonghong Song <yonghong.song@linux.dev> 
>>> wrote:
>>>
>>>
>>> On 12/15/23 6:38 AM, Dave Tucker wrote:
>>>> Current output from auditd is as follows:
>>>>
>>>> time->Wed Dec 13 21:39:24 2023
>>>> type=BPF msg=audit(1702503564.519:11241): prog-id=439 op=LOAD
>>>>
>>>> This only tells you that a BPF program was loaded, but without
>>>> any context. If we include the prog-name, pid, uid and comm we get
>>>> output as follows:
>>>>
>>>> time->Wed Dec 13 21:59:59 2023
>>>> type=BPF msg=audit(1702504799.156:99528): op=UNLOAD prog-id=50092
>>>> prog-name="test" pid=27279 uid=0 comm="new_name"
>>>>
>>>> With pid, uid a system administrator has much better context
>>>> over which processes and user loaded which eBPF programs.
>>>> comm is useful since processes may be short-lived.
>>>>
>>>> Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
>>>> ---
>>>>
>>>> Changes:
>>>>
>>>> v1->v2:
>>>>    - Move 'op' to the front of the audit messages
>>>>    - Add 'prog-name' to the audit messages
>>>>    - Replace deprecated in_irq() with in_hardirq()
>>>>    - Remove in_irq() check from bpf_audit_prog since it's always 
>>>> called
>>>>      from the task context
>>> Is this true? For condition '(in_hardirq() || irqs_disabled())
>>> ', the context will be the task context. But what about nmi and
>>> softirq? The context maynot be the task context, right?
>> You’re right, my mistake.
>>
>>> Not sure whether this is relevant or not. There was a discussion
>>> in the past about the above condition. See
>>> https://lore.kernel.org/bpf/a93079f2-fcd4-e3ef-3b92-92d443b8e8c6@meta.com/
>>>
>>> The recommended change was
>>>
>>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index 
>>> a75c54b6f8a3..11df562e481b 100644 --- a/kernel/bpf/syscall.c +++ 
>>> b/kernel/bpf/syscall.c @@ -2147,7 +2147,7 @@ static void 
>>> __bpf_prog_put(struct bpf_prog *prog)           struct bpf_prog_aux 
>>> *aux = prog->aux;
>>>
>>>          if (atomic64_dec_and_test(&aux->refcnt)) {
>>> - if (in_irq() || irqs_disabled()) { + if (!in_interrupt()) 
>>> {                           INIT_WORK(&aux->work, 
>>> bpf_prog_put_deferred);
>>>                          schedule_work(&aux->work);
>>>                  } else {
>> include/linux/preempt.h says that in_interrupt is also deprecated.
>> The condition could also be expressed as in_task().
>
> Okay, I see. in_interrupt() probably means !in_task(). The key issue
> is in vfree()
> ===
> void vfree(const void *addr)
> {
>         struct vm_struct *vm;
>         int i;
>
>         if (unlikely(in_interrupt())) {
>                 vfree_atomic(addr);
>                 return;
>         }
>
>         BUG_ON(in_nmi());
>         kmemleak_free(addr);
>         might_sleep();
> ...
> ===
> where if in interrupt, vfree is atomic() and otherwise, it is not.
> So if for task context, there are cases in the kernel where
> __bpf_prog_put() is inside rcu critical section and this might
> cause the problem. But since this is true for a couple of cases,
> so it has not been a big issue yet...
>
>>
>>> If the above change was true, then audit will not be able to
>>> get any meaning task specific information, you might need to
>>> gather such informaiton before hand.
>> Hmmm. Would storing that information in bpf_prog_aux work?
>
> I think this is more reliable and actually you might get more
> useful information, considering once going to kthread, you will
> lose task related information.

But for the *current* implementation, you don't need to do that.
You only need to have proper interupt and kthread check in bpf_audit_prog.

>
>>
>> - Dave
>>
>>>
>>>>    - Only populate pid, uid and comm if not in a kthread
>>>>
>>>>   kernel/bpf/syscall.c | 27 ++++++++++++++++++++++-----
>>>>   1 file changed, 22 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>>>> index 06320d9abf33..fbbaf3b8ad48 100644
>>>> --- a/kernel/bpf/syscall.c
>>>> +++ b/kernel/bpf/syscall.c
>>>> @@ -35,6 +35,7 @@
>>>>   #include <linux/rcupdate_trace.h>
>>>>   #include <linux/memcontrol.h>
>>>>   #include <linux/trace_events.h>
>>>> +#include <linux/uidgid.h>
>>>>     #include <net/netfilter/nf_bpf_link.h>
>>>>   #include <net/netkit.h>
>>>> @@ -2110,18 +2111,34 @@ static void bpf_audit_prog(const struct 
>>>> bpf_prog *prog, unsigned int op)
>>>>   {
>>>>    struct audit_context *ctx = NULL;
>>>>    struct audit_buffer *ab;
>>>> + const struct cred *cred;
>>>> + char comm[sizeof(current->comm)];
>>>>      if (WARN_ON_ONCE(op >= BPF_AUDIT_MAX))
>>>>    return;
>>>>    if (audit_enabled == AUDIT_OFF)
>>>>    return;
>>>> - if (!in_irq() && !irqs_disabled())
>>>> - ctx = audit_context();
>>>> +
>>>> + ctx = audit_context();
>>>>    ab = audit_log_start(ctx, GFP_ATOMIC, AUDIT_BPF);
>>>>    if (unlikely(!ab))
>>>>    return;
>>>> - audit_log_format(ab, "prog-id=%u op=%s",
>>>> -  prog->aux->id, bpf_audit_str[op]);
>>>> +
>>>> + audit_log_format(ab, "op=%s prog-id=%u",
>>>> +  bpf_audit_str[op], prog->aux->id);
>>>> + audit_log_format(ab, " prog-name=");
>>>> + audit_log_untrustedstring(ab, prog->aux->name ?: "(none)");
>>>> +
>>>> + if (current->mm) {
>>>> + cred = current_cred();
>>>> + audit_log_format(ab, " pid=%u uid=%u",
>>>> +  task_pid_nr(current),
>>>> +  from_kuid(&init_user_ns, cred->uid));
>>>> + audit_log_format(ab, " comm=");
>>>> + audit_log_untrustedstring(ab, get_task_comm(comm, current));
>>>> + } else {
>>>> + audit_log_format(ab, " pid=? uid=? comm=?");
>>>> + }
>>>>    audit_log_end(ab);
>>>>   }
>>>>   @@ -2212,7 +2229,7 @@ static void __bpf_prog_put(struct bpf_prog 
>>>> *prog)
>>>>    struct bpf_prog_aux *aux = prog->aux;
>>>>      if (atomic64_dec_and_test(&aux->refcnt)) {
>>>> - if (in_irq() || irqs_disabled()) {
>>>> + if (in_hardirq() || irqs_disabled()) {
>>>>    INIT_WORK(&aux->work, bpf_prog_put_deferred);
>>>>    schedule_work(&aux->work);
>>>>    } else {
>>
>

  reply	other threads:[~2023-12-15 17:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-14 12:07 [PATCH bpf-next v1] bpf: Include pid, uid and comm in audit output Dave Tucker
2023-12-14 13:13 ` Yafang Shao
2023-12-14 13:21   ` Yafang Shao
2023-12-14 14:11     ` Dave Tucker
2023-12-14 14:32       ` Yafang Shao
2023-12-15  3:31         ` Alexei Starovoitov
2023-12-15 14:38           ` [PATCH bpf-next v2 1/1] " Dave Tucker
2023-12-15 15:24             ` Yonghong Song
2023-12-15 16:38               ` Dave Tucker
2023-12-15 16:53                 ` Yonghong Song
2023-12-15 17:02                   ` Yonghong Song [this message]
2023-12-15 17:46                     ` [PATCH bpf-next v3] " Dave Tucker
2023-12-15 18:00                       ` Alexei Starovoitov
2023-12-19 18:54                         ` Paul Moore
2023-12-15 22:20                       ` Daniel Borkmann
2023-12-18 16:55                         ` Dave Tucker
2023-12-14 23:30 ` [PATCH bpf-next v1] " Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3636f52d-f343-45e5-88c6-3c7e28e87a45@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dave@dtucker.co.uk \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=martin.lau@linux.dev \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox