Em Mon, Nov 27, 2017 at 04:34:25PM -0300, Arnaldo Carvalho de Melo escreveu:
> So, I noticed that any maps are failing, I'll go dig, but may be some
> new security tightening, even running as root, this was working
> recently, was even part of our discussion on the bpf_probe_read_str()
> trouble with clang's optimizer:
>
> [root@jouet bpf]# cat open.c
> #include "bpf.h"
>
> SEC("prog=do_sys_open filename")
> int prog(void *ctx, int err, char *filename_ptr)
> {
> char filename[128];
> int len = bpf_probe_read_str(filename, sizeof(filename), filename_ptr);
> if (len > 0) {
> if (len == 1)
> perf_event_output(ctx, &__bpf_stdout__,
> BPF_F_CURRENT_CPU, filename, len);
> else if (len < 128)
> perf_event_output(ctx, &__bpf_stdout__,
> BPF_F_CURRENT_CPU, filename, len);
> }
> return 1;
> }
> [root@jouet bpf]#
> <SNIP>
> Found 1 probe_trace_events.
> Opening /sys/kernel/debug/tracing//kprobe_events write=1
> Writing event: p:perf_bpf_probe/prog _text+2493856 filename=%si:x64
> In map_prologue, ntevs=1
> mapping[0]=0
> libbpf: failed to create map (name: '__bpf_stdout__'): Invalid argument
> libbpf: failed to load object 'open.c'
> bpf: load objects failed
> event syntax error: 'open.c'
> \___ Operation not permitted
> <SNIP>
>
> Using 'perf ftrace' to trace just 'perf trace':
>
> [root@jouet bpf]# perf ftrace -G SyS_bpf perf trace -v -e open.c,open cat
> /tmp/somefile 2> /dev/null
> 0) | SyS_bpf() {
> 0) | capable() {
> 0) | ns_capable_common() {
> 0) | security_capable() {
> 0) 0.045 us | cap_capable();
> 0) | selinux_capable() {
> 0) 0.274 us | cred_has_capability();
> 0) 0.518 us | }
> 0) 1.464 us | }
> 0) 1.783 us | }
> 0) 2.130 us | }
> 0) 0.458 us | check_uarg_tail_zero();
> 0) | __check_object_size() {
> 0) 0.046 us | __virt_addr_valid();
> 0) 0.040 us | check_stack_object();
> 0) 0.510 us | }
> 0) 4.161 us | }
> [root@jouet bpf]#
>
> /me goes to look at SyS_bpf() in this kernel... (4.14.0+).
Tracing 'perf trace' with 'perf trace' we see:
# perf trace -e bpf perf trace -e open.c,open cat /tmp/somefile
<SNIP traced 'perf trace' error messages>
0.000 ( 0.015 ms): perf/16767 bpf(cmd: MAP_CREATE, uattr: 0x7ffc3c8c7ac0,
size: 72) = -1 EINVAL Invalid argument
#
Humm,
# perf probe check_stack_object%return 'ret=$retval'
Added new event:
probe:check_stack_object (on check_stack_object%return with ret=$retval)
You can now use it in all perf tools, such as:
perf record -e probe:check_stack_object -aR sleep 1
#
# perf trace -e bpf,probe:check* perf trace -e open.c,open cat /tmp/somefile
<SNIP lots of check_stack_object calls returning 0x0)
4626.779 ( 0.004 ms): perf/31498 bpf(cmd: MAP_CREATE, uattr: 0x7fff7dbbaab0,
size: 72 ) ...
4626.784 ( ): probe:check_stack_object:(ffffffffb625ec30 <-
ffffffffb625ed1f) ret=0x2)
4626.779 ( 0.006 ms): perf/31498 ... [continued]: bpf()) = -1 EINVAL Invalid
argument
<SNIP lots of check_stack_object calls returning 0x0)
check_stack_object returning 0x2 means GOOD_STACK, 0x0 means
NOT_STACK...
- Arnaldo
