BPF List
 help / color / mirror / Atom feed
From: Anton Protopopov <a.s.protopopov@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf@vger.kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	eddyz87@gmail.com, memxor@gmail.com
Subject: Re: [PATCH v2 bpf-next 09/13] bpf: Allow fmod_ret on tagged functions and check the return value
Date: Fri, 13 Nov 2026 12:20:55 +0000	[thread overview]
Message-ID: <avcApw6Q0_DUmWkE@mail.gmail.com> (raw)
In-Reply-To: <20261113050901.1399091-10-alexei.starovoitov@gmail.com>

On 26/11/13 05:08AM, Alexei Starovoitov wrote:
> From: Anton Protopopov <a.s.protopopov@gmail.com>
> 
> 	SEC("fmod_ret/vfs_fallocate")
> 	int BPF_PROG(no_big_files, struct file *file, int mode,
> 		     loff_t offset, loff_t len, int ret)
> 	{
> 		return len > MAX_LEN ? -EFBIG : 0;
> 	}
> 
> This program keeps user space away from a bug below vfs_fallocate() until
> the fixed kernel runs. It does not load: "vfs_fallocate() is not
> modifiable". The build has tagged the function with the errors that it
> returns, the list: "bpf_fmodret_retval:-95,-29,-27,-26,-22,-21,-19,-9,-1".
> 
> Let an fmod_ret program that is not sleepable attach to a tagged function.
> The declared targets stay as they are: what a program returns there is not
> checked. A caller of a tagged function can get each error of the list from
> the function itself.
> The build knows nothing about other values:
> 
> 	R0 at an exit           the trampoline
> 	0                       calls the function
> 	an error of the list    skips it, the caller gets the error
> 	another value           -, the program does not load
> 
> With -EDQUOT in place of -EFBIG:
> 
>   At program exit the register R0 should be 0 or one of -95,-29,-27,..
> 
> The check is static: every value in the range of R0 is 0 or in the list.
> [-27, 0] has -25, which is not in the list. The program above gets to the
> exit in two states, R0 = -27 and R0 = 0. The verifier tests R0 at the
> exit, so flow_join_makes_up() does not join ranges that leave a gap.
> 
> R0 has a 64-bit and a 32-bit range. clang ends "return a && b ? -EPERM : 0"
> with "w0 &= 1; w0 = -w0; exit". That is [0, U32_MAX] and [-1, 0].
> 
> 	target returns   range     R0 at the exit
> 	int              32-bit    w0 = -22        -22, allowed
> 	                           r0 = 1 << 32    rejected
> 	long             64-bit    w0 = -22        4294967274, rejected
> 
> The caller of an int function reads the low 32 bits. The trampoline tests
> all 64 bits: 1 << 32 skips the function and the caller sees 0. So the
> 32-bit range decides only if the high 32 bits are known to be 0. That
> fits the ABI of x86-64 and arm64, see the comment.
> 
> 	What returns to the trampoline
> 	exit of the main program, of an exception callback    checked
> 	cookie of bpf_throw(), default callback               checked
> 	tail call                                             refused
> 	extension of the main program      refused by existing checks
> 
> Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
> Co-developed-by: Alexei Starovoitov <ast@kernel.org>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Please consider taking also this commit from v3, which requires JIT for fmodret functions: https://github.com/aspsk/bpf-next/commit/f8abd203106bc3f0cf978f2292148d4a63f66b26

> [...]

  parent reply	other threads:[~2026-11-13 12:09 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13  5:08 [PATCH v2 bpf-next 00/13] bpf: fmod_ret for each function that returns errors Alexei Starovoitov
2026-11-13  5:08 ` [PATCH v2 bpf-next 01/13] selftests/bpf: Don't depend on the width of a BTF id in verifier_live_stack Alexei Starovoitov
2026-11-13 11:13   ` Anton Protopopov
2026-11-13  5:08 ` [PATCH v2 bpf-next 02/13] resolve_btfids: Read the code of an ELF file by address Alexei Starovoitov
2026-11-13  5:08 ` [PATCH v2 bpf-next 03/13] resolve_btfids: Describe machine instructions with LLVM's MC layer Alexei Starovoitov
2026-11-13 11:45   ` Anton Protopopov
2026-11-13  5:08 ` [PATCH v2 bpf-next 04/13] resolve_btfids: Find the definitions that reach the return value Alexei Starovoitov
2026-11-13  5:08 ` [PATCH v2 bpf-next 05/13] resolve_btfids: Tag the functions that return errors Alexei Starovoitov
2026-11-13  5:08 ` [PATCH v2 bpf-next 06/13] resolve_btfids: Fold the constants of a select without a branch Alexei Starovoitov
2026-11-13 11:59   ` Anton Protopopov
2026-11-13  5:08 ` [PATCH v2 bpf-next 07/13] resolve_btfids: Say which registers an instruction reads Alexei Starovoitov
2026-11-13 12:03   ` Anton Protopopov
2026-11-13  5:08 ` [PATCH v2 bpf-next 08/13] resolve_btfids: Don't list an error that follows work on an argument Alexei Starovoitov
2026-11-13  5:52   ` bot+bpf-ci
2026-11-13 12:14   ` Anton Protopopov
2026-11-13  5:08 ` [PATCH v2 bpf-next 09/13] bpf: Allow fmod_ret on tagged functions and check the return value Alexei Starovoitov
2026-11-13  5:52   ` bot+bpf-ci
2026-11-13 12:20   ` Anton Protopopov [this message]
2026-11-13  5:08 ` [PATCH v2 bpf-next 10/13] selftests/bpf: Test fmod_ret on tagged functions Alexei Starovoitov
2026-11-13  5:08 ` [PATCH v2 bpf-next 11/13] bpf: Mark the arguments of fmod_ret progs as PTR_UNTRUSTED Alexei Starovoitov
2026-11-13 11:09   ` Anton Protopopov
2026-11-13  5:09 ` [PATCH v2 bpf-next 12/13] bpf: Treat the type of an untrusted pointer as a hint Alexei Starovoitov
2026-11-13  5:52   ` bot+bpf-ci
2026-11-13  5:09 ` [PATCH v2 bpf-next 13/13] selftests/bpf: Test untrusted pointers in fmod_ret progs Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=avcApw6Q0_DUmWkE@mail.gmail.com \
    --to=a.s.protopopov@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=memxor@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox