linux-kernel - Re: bpf_errno. Was: [PATCH RFC bpf-next 1/3] bpf: report probe fault to BPF stderr

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: <6200838.lOV4Wx5bFT@7950hx>
Date: Sat, 11 Oct 2025 09:23:15 +0800
From: Menglong Dong <menglong.dong@...ux.dev>
To: Eduard Zingerman <eddyz87@...il.com>
Cc: Kumar Kartikeya Dwivedi <memxor@...il.com>,
 Alexei Starovoitov <alexei.starovoitov@...il.com>,
 Leon Hwang <hffilwlqm@...il.com>, Andrii Nakryiko <andrii@...nel.org>,
 Menglong Dong <menglong8.dong@...il.com>,
 Alexei Starovoitov <ast@...nel.org>, bpf <bpf@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>,
 linux-trace-kernel <linux-trace-kernel@...r.kernel.org>, jiang.biao@...ux.dev
Subject:
 Re: bpf_errno. Was: [PATCH RFC bpf-next 1/3] bpf: report probe fault to BPF
 stderr

On 2025/10/11 02:55, Eduard Zingerman wrote:
> On Fri, 2025-10-10 at 20:05 +0800, Menglong Dong wrote:
> 
> [...]
> 
> > save errno to r0(Eduard)
> > -----------------------------------
> > Save the errno to r0 in the exception handler of BPF_PROBE_MEM,
> > and read r0 with a __kfun in BPF program. (Not sure if I understand
> > it correctly).
> > 
> > This sounds effective, but won't this break the usage of r0? I mean,
> > the r0 can be used by the BPF program somewhere.
> 
> What I meant is that for cases when someone wants to check for memory
> access error, there is already bpf_probe_read_kernel(). It's return
> value in r0 and is defined for both success and failure cases.
> 
> The problem with it, is that it has a function call overhead.
> But we can workaround that for 1,2,4,8 byte accesses, by replacing
> helper call by some `BPF_LDX | BPF_PROBE_MEM1 | <size>`,
> where BPF_PROBE_MEM1 is different from BPF_PROBE_MEM and tells
> jit that exception handler for this memory access needs to set
> r0 to -EFAULT if it is executed.
> 
> The inconvenient part here is that one can't do chaining,
> like a->b->c, using bpf_probe_read_kernel().
> One needs to insert bpf_probe_read_kernel() call at each step of a
> chain, which is a bit of a pain.  Maybe it can be alleviated using
> some vararg macro.

Thanks for the explication, and I see now.

Interesting idea, and I think this is something that we can do
despite this problem, which can optimize the performance of
bpf_probe_read_kernel().

Thanks!
Menglong Dong

> 
> [...]
> 
>