[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191114230117.wtusupri5p5xw63b@ast-mbp.dhcp.thefacebook.com>
Date: Thu, 14 Nov 2019 15:01:19 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Song Liu <songliubraving@...com>
Cc: Alexei Starovoitov <ast@...nel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"daniel@...earbox.net" <daniel@...earbox.net>,
"x86@...nel.org" <x86@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH v4 bpf-next 15/20] bpf: Annotate context types
On Thu, Nov 14, 2019 at 10:55:37PM +0000, Song Liu wrote:
>
>
> > On Nov 14, 2019, at 10:57 AM, Alexei Starovoitov <ast@...nel.org> wrote:
> >
> > Annotate BPF program context types with program-side type and kernel-side type.
> > This type information is used by the verifier. btf_get_prog_ctx_type() is
> > used in the later patches to verify that BTF type of ctx in BPF program matches to
> > kernel expected ctx type. For example, the XDP program type is:
> > BPF_PROG_TYPE(BPF_PROG_TYPE_XDP, xdp, struct xdp_md, struct xdp_buff)
> > That means that XDP program should be written as:
> > int xdp_prog(struct xdp_md *ctx) { ... }
> >
> > Signed-off-by: Alexei Starovoitov <ast@...nel.org>
> >
>
> [...]
>
> > + /* only compare that prog's ctx type name is the same as
> > + * kernel expects. No need to compare field by field.
> > + * It's ok for bpf prog to do:
> > + * struct __sk_buff {};
> > + * int socket_filter_bpf_prog(struct __sk_buff *skb)
> > + * { // no fields of skb are ever used }
> > + */
> > + if (strcmp(ctx_tname, tname))
> > + return NULL;
>
> Do we need to check size of the two struct? I guess we should not
> allow something like
>
> struct __sk_buff {
> char data[REALLY_BIG_NUM];
> };
> int socket_filter_bpf_prog(struct __sk_buff *skb)
> { /* access end of skb */ }
I don't think we should check sizes either. Same comment above applies. The
prog's __sk_buff can be different from kernel's view into __sk_buff. Either
bigger or larger doesn't matter. If it's accessed by the prog the verifier will
check that all accessed fields are correct. Extra unused fields (like char
data[REALLY_BIG_NUM];) don't affect safety.
When bpf-tracing is attaching to bpf-skb it doesn't use bpf-skb's
__sk_buff with giant fake data[BIG_NUM];. It's using kernel's __sk_buff.
That is what btf_translate_to_vmlinux() in patch 17 is doing.
Powered by blists - more mailing lists