linux-kernel - Re: [PATCHv2] bpf: add bpf_msleep

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] [day] [month] [year] [list]

Message-ID: <CAEf4BzZ_5+717wK7g-3zuB6=DL-yfN6YYX=6RdZNf+DJfnkyhg@mail.gmail.com>
Date: Fri, 23 May 2025 10:17:25 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	John Fastabend <john.fastabend@...il.com>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Matt Bobrowski <mattbobrowski@...gle.com>, bpf@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2] bpf: add bpf_msleep_interruptible() kfunc

On Fri, May 23, 2025 at 12:23 AM Sergey Senozhatsky
<senozhatsky@...omium.org> wrote:
>
> On (25/05/20 16:26), Andrii Nakryiko wrote:
> > On Wed, May 14, 2025 at 11:48 PM Sergey Senozhatsky
> > <senozhatsky@...omium.org> wrote:
> > >
> > > bpf_msleep_interruptible() puts a calling context into an
> > > interruptible sleep.  This function is expected to be used
> > > for testing only (perhaps in conjunction with fault-injection)
> > > to simulate various execution delays or timeouts.
> > >
> > > Signed-off-by: Sergey Senozhatsky <senozhatsky@...omium.org>
> > > ---
> > >
> > > v2:
> > > -- switched to kfunc (Matt)
> > >
> > >  kernel/bpf/helpers.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> > > index fed53da75025..a7404ab3b0b8 100644
> > > --- a/kernel/bpf/helpers.c
> > > +++ b/kernel/bpf/helpers.c
> > > @@ -24,6 +24,7 @@
> > >  #include <linux/bpf_mem_alloc.h>
> > >  #include <linux/kasan.h>
> > >  #include <linux/bpf_verifier.h>
> > > +#include <linux/delay.h>
> > >
> > >  #include "../../lib/kstrtox.h"
> > >
> > > @@ -3283,6 +3284,11 @@ __bpf_kfunc void bpf_local_irq_restore(unsigned long *flags__irq_flag)
> > >         local_irq_restore(*flags__irq_flag);
> > >  }
> > >
> > > +__bpf_kfunc unsigned long bpf_msleep_interruptible(unsigned int msecs)
> > > +{
> > > +       return msleep_interruptible(msecs);
> > > +}
> > > +
> >
> > What happened to the trying out custom kernel module for
> > fuzzing/testing use case you have?
>
> Oh, my bad.  I think it wasn't clear to me that this was the final
> conclusion, it looked to me that the conversation ended up with a
> number of open questions.
>
> > I'll repeat my concerns. BPF maps and progs are all interdependent
> > between each other by global RCU Tasks Trace "domain". Delay one RCU
> > tasks trace grace period through the use of msleep() will delay
> > everything BPF-related in the entire kernel.
> >
> > Until we have some way to give some of BPF programs and its isolated
> > BPF maps its own RCU domain, I don't think we should allow arbitrary
> > sleeps inside BPF programs.
>
> I see.  How are sleepable BPF programs operate wrt RCU currently?

What we call "sleepable BPF" is really "faultable BPF", meaning we
only allow the kernel to handle page faults to bring data into
physical memory. There is no real sleeping (though userfaultfd is its
own set of problems when it comes to page fault predictability). So we
consider this fault delay to be bounded. With msleep() that
boundedness is explicitly abandoned.