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]
Date:	Tue, 26 Jan 2016 13:07:45 -0200
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Wang Nan <wangnan0@...wei.com>
Cc:	Alexei Starovoitov <ast@...nel.org>, acme@...nel.org,
	Brendan Gregg <brendan.d.gregg@...il.com>,
	Daniel Borkmann <daniel@...earbox.net>,
	"David S. Miller" <davem@...emloft.net>,
	He Kuang <hekuang@...wei.com>, Jiri Olsa <jolsa@...nel.org>,
	Li Zefan <lizefan@...wei.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>, pi3orama@....com,
	Will Deacon <will.deacon@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/54] perf test: Add libbpf relocation checker

Em Tue, Jan 26, 2016 at 12:58:50PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Jan 25, 2016 at 09:55:48AM +0000, Wang Nan escreveu:
> > There's a bug in LLVM that it can generate unneeded relocation
> > information. See [1] and [2]. Libbpf should check the target section
> > of a relocation symbol.
> > 
> > This patch adds a testcase which reference a global variable (BPF
> > doesn't support global variable). Before fixing libbpf, the new test
> > case can be loaded into kernel, the global variable acts like the first
> > map. It is incorrect.
> > 
> > Result:
> >  # ~/perf test BPF
> >  37: Test BPF filter                                          :
> >  37.1: Test basic BPF filtering                               : Ok
> >  37.2: Test BPF prologue generation                           : Ok
> >  37.3: Test BPF relocation checker                            : FAILED!
> > 
> >  # ~/perf test -v BPF
> >  ...
> >  libbpf: loading object '[bpf_relocation_test]' from buffer
> >  libbpf: section .strtab, size 126, link 0, flags 0, type=3
> >  libbpf: section .text, size 0, link 0, flags 6, type=1
> >  libbpf: section .data, size 0, link 0, flags 3, type=1
> >  libbpf: section .bss, size 0, link 0, flags 3, type=8
> >  libbpf: section func=sys_write, size 104, link 0, flags 6, type=1
> >  libbpf: found program func=sys_write
> >  libbpf: section .relfunc=sys_write, size 16, link 10, flags 0, type=9
> >  libbpf: section maps, size 16, link 0, flags 3, type=1
> >  libbpf: maps in [bpf_relocation_test]: 16 bytes
> >  libbpf: section license, size 4, link 0, flags 3, type=1
> >  libbpf: license of [bpf_relocation_test] is GPL
> >  libbpf: section version, size 4, link 0, flags 3, type=1
> >  libbpf: kernel version of [bpf_relocation_test] is 40400
> >  libbpf: section .symtab, size 144, link 1, flags 0, type=2
> >  libbpf: map 0 is "my_table"
> >  libbpf: collecting relocating info for: 'func=sys_write'
> >  libbpf: relocation: insn_idx=7
> >  Success unexpectedly: libbpf error when dealing with relocation
> 
> "Success unexpectedly?" Reading the code to try to grok this message...

        obj = prepare_bpf(obj_buf, obj_buf_sz,
                          bpf_testcase_table[idx].name);
        if ((!!bpf_testcase_table[idx].target_func) != (!!obj)) {
                if (!obj)
                        pr_debug("Fail to load BPF object: %s\n",
                                 bpf_testcase_table[idx].msg_load_fail);
                else
                        pr_debug("Success unexpectedly: %s\n",
                                 bpf_testcase_table[idx].msg_load_fail);
                ret = TEST_FAIL;
                goto out;
        }


Ok, so in this case you have target_func == NULL, and you managed to
prepare the bpf object, that shouldn't been the case, i.e. prepare_obj
should've returned NULL.

Perhaps replace that "Success unexpectedly"  with "Unexpected sucess,
this script is invalid, should've been marked as such by function
libbpf_foo()"?

Now to apply the follow up patch to see how that will make this test
work as expected...

- Arnaldo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ