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]
Message-ID: <6264da10-b6a0-40b8-ac26-c044b7f7529c@I-love.SAKURA.ne.jp>
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 ?


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ