netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net-next] bpf: fix loading of BPF_MAXINSNS sized programs
@ 2016-12-07  0:15 Daniel Borkmann
  2016-12-07  9:42 ` Sergei Shtylyov
  2016-12-07 18:18 ` David Miller
  0 siblings, 2 replies; 4+ messages in thread
From: Daniel Borkmann @ 2016-12-07  0:15 UTC (permalink / raw)
  To: davem; +Cc: alexei.starovoitov, netdev, Daniel Borkmann

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
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@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
 ( net-next is just fine imho. )

 kernel/bpf/syscall.c  | 4 ++--
 kernel/bpf/verifier.c | 3 ---
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index c0d2b42..88f609f 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -786,8 +786,8 @@ static int bpf_prog_load(union bpf_attr *attr)
 	/* eBPF programs must be GPL compatible to use GPL-ed functions */
 	is_gpl = license_is_gpl_compatible(license);
 
-	if (attr->insn_cnt >= BPF_MAXINSNS)
-		return -EINVAL;
+	if (attr->insn_cnt == 0 || attr->insn_cnt > BPF_MAXINSNS)
+		return -E2BIG;
 
 	if (type == BPF_PROG_TYPE_KPROBE &&
 	    attr->kern_version != LINUX_VERSION_CODE)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index cb37339..da9fb2a 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3133,9 +3133,6 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr)
 	struct bpf_verifier_env *env;
 	int ret = -EINVAL;
 
-	if ((*prog)->len <= 0 || (*prog)->len > BPF_MAXINSNS)
-		return -E2BIG;
-
 	/* 'struct bpf_verifier_env' can be global, but since it's not small,
 	 * allocate/free it every time bpf_check() is called
 	 */
-- 
1.9.3

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH net-next] bpf: fix loading of BPF_MAXINSNS sized programs
  2016-12-07  0:15 [PATCH net-next] bpf: fix loading of BPF_MAXINSNS sized programs Daniel Borkmann
@ 2016-12-07  9:42 ` Sergei Shtylyov
  2016-12-07  9:53   ` Daniel Borkmann
  2016-12-07 18:18 ` David Miller
  1 sibling, 1 reply; 4+ messages in thread
From: Sergei Shtylyov @ 2016-12-07  9:42 UTC (permalink / raw)
  To: Daniel Borkmann, davem; +Cc: alexei.starovoitov, netdev

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.

> 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@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
[...]

MBR, Sergei

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH net-next] bpf: fix loading of BPF_MAXINSNS sized programs
  2016-12-07  9:42 ` Sergei Shtylyov
@ 2016-12-07  9:53   ` Daniel Borkmann
  0 siblings, 0 replies; 4+ messages in thread
From: Daniel Borkmann @ 2016-12-07  9:53 UTC (permalink / raw)
  To: Sergei Shtylyov, davem; +Cc: alexei.starovoitov, netdev

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@iogearbox.net>
>> Acked-by: Alexei Starovoitov <ast@kernel.org>
> [...]
>
> MBR, Sergei

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH net-next] bpf: fix loading of BPF_MAXINSNS sized programs
  2016-12-07  0:15 [PATCH net-next] bpf: fix loading of BPF_MAXINSNS sized programs Daniel Borkmann
  2016-12-07  9:42 ` Sergei Shtylyov
@ 2016-12-07 18:18 ` David Miller
  1 sibling, 0 replies; 4+ messages in thread
From: David Miller @ 2016-12-07 18:18 UTC (permalink / raw)
  To: daniel; +Cc: alexei.starovoitov, netdev

From: Daniel Borkmann <daniel@iogearbox.net>
Date: Wed,  7 Dec 2016 01:15:44 +0100

> 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
> 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@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
> ---
>  ( net-next is just fine imho. )

Applied.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-12-07 18:18 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-12-07  0:15 [PATCH net-next] bpf: fix loading of BPF_MAXINSNS sized programs Daniel Borkmann
2016-12-07  9:42 ` Sergei Shtylyov
2016-12-07  9:53   ` Daniel Borkmann
2016-12-07 18:18 ` David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).