netdev - Re: [PATCH v4 bpf-next 15/20] bpf: Annotate context types

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: <E4C70DF1-372F-4129-94DB-E036FB262BEA@fb.com>
Date:   Thu, 14 Nov 2019 23:19:09 +0000
From:   Song Liu <songliubraving@...com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.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 Nov 14, 2019, at 3:01 PM, Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
> 
> 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.

I see. Thanks for the pointer. 

Song