netdev - Re: [PATCH net-next] bpf: fix loading of BPF

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: <5847DC11.1040805@iogearbox.net>
Date:   Wed, 07 Dec 2016 10:53:21 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        davem@...emloft.net
CC:     alexei.starovoitov@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] bpf: fix loading of BPF_MAXINSNS sized programs

On 12/07/2016 10:42 AM, Sergei Shtylyov wrote:
> Hello!
>
> On 12/7/2016 3:15 AM, Daniel Borkmann wrote:
>
>> General assumption is that single program can hold up to BPF_MAXINSNS,
>> that is, 4096 number of instructions. It is the case with cBPF and
>
>     Up to BPF_MAXINSNS (that is 4096) instructions.

Thanks for nitpicking, I think it's just fine as-is.

>> that limit was carried over to eBPF. When recently testing digest, I
>> noticed that it's actually not possible to feed 4096 instructions
>> via bpf(2).
>>
>> The check for > BPF_MAXINSNS was added back then to bpf_check() in
>> cbd357008604 ("bpf: verifier (add ability to receive verification log)").
>> However, 09756af46893 ("bpf: expand BPF syscall with program load/unload")
>> added yet another check that comes before that into bpf_prog_load(),
>> but this time bails out already in case of >= BPF_MAXINSNS.
>>
>> Fix it up and perform the check early in bpf_prog_load(), so we can drop
>> the second one in bpf_check(). It makes sense, because also a 0 insn
>> program is useless and we don't want to waste any resources doing work
>> up to bpf_check() point. The existing bpf(2) man page documents E2BIG
>> as the official error for such cases, so just stick with it as well.
>>
>> Fixes: 09756af46893 ("bpf: expand BPF syscall with program load/unload")
>> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
>> Acked-by: Alexei Starovoitov <ast@...nel.org>
> [...]
>
> MBR, Sergei