netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Gianluca Borello <g.borello@gmail.com>,
	Alexei Starovoitov <ast@kernel.org>,
	David Miller <davem@davemloft.net>,
	Linux Networking Development Mailing List
	<netdev@vger.kernel.org>,
	yhs@fb.com
Subject: Re: len = bpf_probe_read_str(); bpf_perf_event_output(... len) == FAIL
Date: Tue, 14 Nov 2017 10:42:29 -0300	[thread overview]
Message-ID: <20171114134229.GO8836@kernel.org> (raw)
In-Reply-To: <b1c2575f-7663-4adf-dbb7-aaa9df15b283@iogearbox.net>

Em Tue, Nov 14, 2017 at 02:09:34PM +0100, Daniel Borkmann escreveu:
> On 11/14/2017 01:58 PM, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Nov 14, 2017 at 01:09:39AM +0100, Daniel Borkmann escreveu:
> >> On 11/13/2017 04:08 PM, Arnaldo Carvalho de Melo wrote:
> >>> libbpf: -- BEGIN DUMP LOG ---
> >>> libbpf: 
> >>> 0: (79) r3 = *(u64 *)(r1 +104)
> >>> 1: (b7) r2 = 0
> >>> 2: (bf) r6 = r1
> >>> 3: (bf) r1 = r10
> >>> 4: (07) r1 += -128
> >>> 5: (b7) r2 = 128
> >>> 6: (85) call bpf_probe_read_str#45
> >>> 7: (bf) r1 = r0
> >>> 8: (07) r1 += -1
> >>> 9: (67) r1 <<= 32
> >>> 10: (77) r1 >>= 32
> >>> 11: (25) if r1 > 0x7f goto pc+11
> >>
> >> Right, so the compiler is optimizing the two tests into a single one above,
> >> which means lower bound cannot properly be derived again by the verifier due
> >> to this and thus you'll get the error. Similar issue was seen recently [1].
> >>
> >> Does the below hack work for you?
> >>
> >> int prog([...])
> >> {
> >>         char filename[128];
> >>         int ret = bpf_probe_read_str(filename, sizeof(filename), filename_ptr);
> >>         if (ret > 0)
> >>                 bpf_perf_event_output(ctx, &__bpf_stdout__, BPF_F_CURRENT_CPU, filename,
> >>                                       ret & (sizeof(filename) - 1));
> >>         return 1;
> >> }
> >>
> >> r0 should keep on tracking bounds here at least:
> >>
> >> prog:
> >>        0:	bf 16 00 00 00 00 00 00 	r6 = r1
> >>        1:	bf a1 00 00 00 00 00 00 	r1 = r10
> >>        2:	07 01 00 00 80 ff ff ff 	r1 += -128
> >>        3:	b7 02 00 00 80 00 00 00 	r2 = 128
> >>        4:	85 00 00 00 2d 00 00 00 	call 45
> >>        5:	67 00 00 00 20 00 00 00 	r0 <<= 32
> >>        6:	c7 00 00 00 20 00 00 00 	r0 s>>= 32
> >>        7:	b7 01 00 00 01 00 00 00 	r1 = 1
> >>        8:	6d 01 0a 00 00 00 00 00 	if r1 s> r0 goto 10
> >>        9:	57 00 00 00 7f 00 00 00 	r0 &= 127
> >>       10:	bf a4 00 00 00 00 00 00 	r4 = r10
> >>       11:	07 04 00 00 80 ff ff ff 	r4 += -128
> >>       12:	bf 61 00 00 00 00 00 00 	r1 = r6
> >>       13:	18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 	r2 = 0ll
> >>       15:	18 03 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 	r3 = 4294967295ll
> >>       17:	bf 05 00 00 00 00 00 00 	r5 = r0
> >>       18:	85 00 00 00 19 00 00 00 	call 25
> >>
> >>   [1] http://patchwork.ozlabs.org/project/netdev/list/?series=13211
> > 
> > Not yet:
> > 
> > 6: (85) call bpf_probe_read_str#45
> > 7: (bf) r1 = r0
> > 8: (67) r1 <<= 32
> > 9: (77) r1 >>= 32
> > 10: (15) if r1 == 0x0 goto pc+10
> >  R0=inv(id=0) R1=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R6=ctx(id=0,off=0,imm=0) R10=fp0
> > 11: (57) r0 &= 127
> > 12: (bf) r4 = r10
> > 13: (07) r4 += -128
> > 14: (bf) r1 = r6
> > 15: (18) r2 = 0xffff92bfc2aba840
> > 17: (18) r3 = 0xffffffff
> > 19: (bf) r5 = r0
> > 20: (85) call bpf_perf_event_output#25
> > invalid stack type R4 off=-128 access_size=0
> > 
> > I'll try updating clang/llvm...
> > 
> > Full details:
> > 
> > [root@jouet bpf]# cat open.c 
> > #include "bpf.h"
> > 
> > SEC("prog=do_sys_open filename")
> > int prog(void *ctx, int err, const char __user *filename_ptr)
> > {
> > 	char filename[128];
> > 	const unsigned len = bpf_probe_read_str(filename, sizeof(filename), filename_ptr);
> 
> Btw, I was using 'int' here above instead of 'unsigned' as strncpy_from_unsafe()
> could potentially return errors like -EFAULT.

I changed to int, didn't help
 
> Currently having a version compiled from the git tree:
> 
> # llc --version
> LLVM (http://llvm.org/):
>   LLVM version 6.0.0git-2d810c2
>   Optimized build.
>   Default target: x86_64-unknown-linux-gnu
>   Host CPU: skylake

[root@jouet bpf]# llc --version
LLVM (http://llvm.org/):
  LLVM version 4.0.0svn

Old stuff! ;-) Will change, but improving these messages should be on
the radar, I think :-)

- Arnaldo
 
>   Registered Targets:
>     bpf    - BPF (host endian)
>     bpfeb  - BPF (big endian)
>     bpfel  - BPF (little endian)
>     x86    - 32-bit X86: Pentium-Pro and above
>     x86-64 - 64-bit X86: EM64T and AMD64
> 
> > 	if (len > 0)
> >        		perf_event_output(ctx, &__bpf_stdout__, BPF_F_CURRENT_CPU, filename,
> > 				  len & (sizeof(filename) - 1));
> > 	return 1;
> > }

  reply	other threads:[~2017-11-14 13:42 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 14:30 len = bpf_probe_read_str(); bpf_perf_event_output(... len) == FAIL Arnaldo Carvalho de Melo
2017-11-13 14:56 ` Daniel Borkmann
2017-11-13 15:08   ` Arnaldo Carvalho de Melo
2017-11-14  0:09     ` Daniel Borkmann
2017-11-14 12:58       ` Arnaldo Carvalho de Melo
2017-11-14 13:09         ` Daniel Borkmann
2017-11-14 13:42           ` Arnaldo Carvalho de Melo [this message]
2017-11-14 14:19             ` Daniel Borkmann
2017-11-14 14:58               ` Arnaldo Carvalho de Melo
2017-11-14 18:15               ` Yonghong Song
2017-11-14 20:25                 ` Daniel Borkmann
2017-11-14 22:58                   ` Yonghong Song
2017-11-21 14:29                     ` Arnaldo Carvalho de Melo
2017-11-21 22:31                       ` Alexei Starovoitov
2017-11-22 18:42                         ` Gianluca Borello
2018-01-22 15:06                           ` Arnaldo Carvalho de Melo
2018-01-22 18:28                             ` Yonghong Song
2018-01-22 20:52                               ` Arnaldo Carvalho de Melo
2017-11-20 13:31                   ` Arnaldo Carvalho de Melo
2017-11-20 16:47                     ` Yonghong Song

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=20171114134229.GO8836@kernel.org \
    --to=acme@kernel.org \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=g.borello@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=yhs@fb.com \
    /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 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).