From: Eduard Zingerman <eddyz87@gmail.com>
To: Yonghong Song <yonghong.song@linux.dev>,
bpf@vger.kernel.org, ast@kernel.org
Cc: andrii@kernel.org, daniel@iogearbox.net, martin.lau@linux.dev,
kernel-team@fb.com, jose.marchesi@oracle.com
Subject: Re: [PATCH bpf-next 0/1] use preserve_static_offset in bpf uapi headers
Date: Fri, 08 Dec 2023 22:54:45 +0200 [thread overview]
Message-ID: <dca277be58dc7e86ffd16e10c1e49370aa48eda2.camel@gmail.com> (raw)
In-Reply-To: <9e4e70d9-aeda-4100-a879-1b7413db567d@linux.dev>
On Fri, 2023-12-08 at 09:19 -0800, Yonghong Song wrote:
> On 12/8/23 6:34 AM, Eduard Zingerman wrote:
> > On Thu, 2023-12-07 at 18:28 -0800, Yonghong Song wrote:
> > [...]
> > > All context types are defined in include/linux/bpf_types.h.
> > > The context type bpf_nf_ctx is missing.
[...]
> The error message should happen here:
>
> check_mem_access
> ...
> } else if (reg->type == PTR_TO_CTX) {
> check_ptr_off_reg
> __check_ptr_off_reg
> if (!fixed_off_ok && reg->off) {
> verbose(env, "dereference of modified %s ptr R%d off=%d disallowed\n",
> reg_type_str(env, reg->type), regno, reg->off);
> return -EACCES;
> }
> ...
>
> So the verification error message will be emitted earlier, before convert_ctx_access.
> Could you double check?
You are correct and I was unaware of this check. A simple test
"r1 += 8; r0 = *(u64 *)(r1 + 0);" does indeed report an error.
I'll make sure that every context type is annotated with
preserve static offset, thank you for pointing this out.
[...]
next prev parent reply other threads:[~2023-12-08 20:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-08 0:05 [PATCH bpf-next 0/1] use preserve_static_offset in bpf uapi headers Eduard Zingerman
2023-12-08 0:05 ` [PATCH bpf-next 1/1] bpf: Mark virtual BPF context structures as preserve_static_offset Eduard Zingerman
2023-12-08 3:36 ` Yonghong Song
2023-12-08 14:23 ` Eduard Zingerman
2023-12-08 2:28 ` [PATCH bpf-next 0/1] use preserve_static_offset in bpf uapi headers Yonghong Song
2023-12-08 14:34 ` Eduard Zingerman
2023-12-08 17:19 ` Yonghong Song
2023-12-08 20:54 ` Eduard Zingerman [this message]
2023-12-08 17:30 ` Yonghong Song
2023-12-08 17:46 ` Alexei Starovoitov
2023-12-08 20:35 ` Eduard Zingerman
2023-12-08 12:27 ` Alan Maguire
2023-12-08 14:21 ` Eduard Zingerman
2023-12-08 15:35 ` Alan Maguire
2023-12-08 15:39 ` Eduard Zingerman
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=dca277be58dc7e86ffd16e10c1e49370aa48eda2.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jose.marchesi@oracle.com \
--cc=kernel-team@fb.com \
--cc=martin.lau@linux.dev \
--cc=yonghong.song@linux.dev \
/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.