linux-kernel - Re: [PATCH] bpf: defer printk() inside __bpf_prog

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 27 Jun 2024 08:08:57 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>,
        John Ogness <john.ogness@...utronix.de>,
        Alexei Starovoitov
 <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau
 <martin.lau@...ux.dev>,
        Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>,
        Yonghong Song <yonghong.song@...ux.dev>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>,
        Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        bpf <bpf@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] bpf: defer printk() inside __bpf_prog_run()

On 2024/06/27 7:33, Steven Rostedt wrote:
> So you are saying that because a BPF hook can attach to a tracepoint
> that is called with rq locks held, it should always disable preemption
> and call printk_deferred_enter(), because it *might* hit an error path
> that will call printk?? In other words, how the BPF hook is used
> determines if the rq lock is held or not when it is called.

Yes.

> 
> I can use that same argument for should_fail_ex(). Because how it is
> used determines if the rq lock is held or not when it is called. And it
> is the function that actually calls printk().

Strictly speaking, KASAN/KMSAN/KCSAN etc. *might* call printk() at any location.
In that aspect, just wrapping individual function that explicitly calls printk()
might not be sufficient. We will need to widen section for deferring printk(),
but we don't want to needlessly call migrate_disable()/preempt_disable()/
printk_deferred_enter() due to performance reason. We need to find a balanced
location for calling migrate_disable()/preempt_disable()/printk_deferred_enter().
I consider __bpf_prog_run() as a balanced location.

> 
> Sorry, but it makes no sense to put the burden of the
> printk_deferred_enter() on the BPF hook logic. It should sit solely
> with the code that actually calls printk().

How do you respond to Petr Mladek's comment

  Yeah, converting printk() into printk_deferred() or using
  printk_deferred_enter() around particular code paths is a whac-a-mole
  game.

at https://lkml.kernel.org/r/ZnvVQ5cs9F0b7paI@pathway.suse.cz ?