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

Message-ID: <6485d7de-2af6-48d6-b427-66d3697ec2b2@gmail.com>
Date: Thu, 9 Oct 2025 23:15:40 +0800
From: Leon Hwang <hffilwlqm@...il.com>
To: Kumar Kartikeya Dwivedi <memxor@...il.com>,
 Eduard Zingerman <eddyz87@...il.com>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>,
 Andrii Nakryiko <andrii@...nel.org>, Menglong Dong
 <menglong.dong@...ux.dev>, 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

>>
>> Since we're piling on ideas, one of the other things that I think
>> could be useful in general (and maybe should be done orthogonally to
>> bpf_errno)
>> is making some empty nop function and making it not traceable reliably
>> across arches and invoke it in the bpf exception handler.
> 
> No new traceable function is needed, since ex_handler_bpf itself can
> already be traced via fentry.
> 
> If users really want to detect whether a fault occurred, they could
> attach a program to ex_handler_bpf and record fault events into a map.
> However, this approach would be too heavyweight just to check for a
> simple fault condition.
> 

As ex_handler_bpf can already be traced using fentry, a potential
approach without modifying the kernel would be:

1. In the fentry program:

int is_fault SEC(".percpu.fault");

SEC("fentry/ex_handler_bpf")
int BPF_PROG(f__ex, const struct exception_table_entry *x, struct
pt_regs *regs)
{
    is_fault = 1;
    return 0;
}

2. In the main program:

int is_fault SEC(".percpu.fault");

is_fault = 0;
/* probe read */
if (is_fault)
    /* handle fault */;

The main idea is that both programs share the same ".percpu.fault" map,
so the variable 'is_fault' can be accessed from both sides.

Here, ".percpu.fault" represents a percpu_array map section, which is
expected to be supported in the future.
In the meantime, it can simply be replaced with a regular percpu_array map.

Finally, this approach is conceptually similar to the idea of using a
global errno.

Thanks,
Leon