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 11/13] bpf: Mark the arguments of fmod_ret progs as PTR_UNTRUSTED
Date: Fri, 13 Nov 2026 11:09:00 +0000 [thread overview]
Message-ID: <avbvzPFUFQOB4iYj@mail.gmail.com> (raw)
In-Reply-To: <20261113050901.1399091-12-alexei.starovoitov@gmail.com>
On 26/11/13 05:08AM, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@kernel.org>
>
> fmod_ret attaches to about 12000 kernel functions now. Nobody looked at
> what these functions get. A pointer argument can be NULL, an ERR_PTR(),
> stale, or an object that is not set up yet.
>
> SEC("fmod_ret/tcp_v4_connect")
> int BPF_PROG(guard, struct sock *sk, struct sockaddr_unsized *addr,
> int addr_len, int ret)
> {
> if (bpf_get_socket_cookie(sk) == cookie)
>
> sk is PTR_TO_BTF_ID without a flag. The verifier does not rely on such
> a pointer: each load through it is BPF_PROBE_MEM, stores are refused,
> kfuncs want a trusted pointer. But helpers take it, for compatibility, and
> dereference it.
>
> PTR_UNTRUSTED is the flag of a pointer that nobody vouches for. Such
> a pointer can do what PTR_TO_BTF_ID without a flag can, except that
> helpers refuse it:
>
> R1 type=untrusted_ptr_ expected=sock_common, sock, tcp_sock, ..
>
> What is loaded through an untrusted pointer is untrusted too, also a __user
> or a __percpu member.
>
> That holds for each fmod_ret prog, also on a target that is allowed today:
> security_*(), a syscall, the error injection list. A prog there does not
> load any more if a helper that expects a kernel object gets an argument:
>
> SEC("fmod_ret/security_file_open")
> bpf_d_path(&file->f_path, buf, sizeof(buf));
>
> bpf_probe_read_kernel() takes each address, as before. All fmod_ret progs
> of the selftests, Tetragon, runtime-enforcer and bad-bpf load as before.
>
> The arguments of fentry and fexit progs keep their type for now.
I am not 100% following why this change is needed without enforcing
this for fentry as well. One can attach fentry before fmodret and
follow all the same args. (But in general, +1 for this and the
following patches.)
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> kernel/bpf/btf.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 228b93d4f8c9..4ed660dc4612 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -7618,6 +7618,8 @@ bool btf_ctx_access(int off, int size, enum bpf_access_type type,
> info->reg_type = PTR_TO_BTF_ID;
> if (prog_args_trusted(prog))
> info->reg_type |= PTR_TRUSTED;
> + else if (prog->expected_attach_type == BPF_MODIFY_RETURN)
> + info->reg_type |= PTR_UNTRUSTED;
>
> if (btf_param_match_suffix(btf, &args[arg], "__nullable"))
> info->reg_type |= PTR_MAYBE_NULL;
> --
> 2.55.0
>
next prev parent reply other threads:[~2026-11-13 10:57 UTC|newest]
Thread overview: 18+ 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 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 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 5:08 ` [PATCH v2 bpf-next 07/13] resolve_btfids: Say which registers an instruction reads Alexei Starovoitov
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 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 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 [this message]
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=avbvzPFUFQOB4iYj@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.