All of lore.kernel.org
 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 08:53:02 -0800	[thread overview]
Message-ID: <c61810a0-4b62-415f-abb7-45868fc91d16@linux.dev> (raw)
In-Reply-To: <ACEF8947-8BE1-429C-AB6E-FE20CFB8CE8D@dtucker.co.uk>


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.

>
> - 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 16:53 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 [this message]
2023-12-15 17:02                   ` Yonghong Song
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=c61810a0-4b62-415f-abb7-45868fc91d16@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.