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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 25 Oct 2020 20:01:47 +0100 From: Jiri Olsa <jolsa@...hat.com> To: Steven Rostedt <rostedt@...dmis.org> Cc: Jiri Olsa <jolsa@...nel.org>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andriin@...com>, netdev@...r.kernel.org, bpf@...r.kernel.org, Martin KaFai Lau <kafai@...com>, Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>, John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...omium.org>, Daniel Xu <dxu@...uu.xyz>, Jesper Brouer <jbrouer@...hat.com>, Toke Høiland-Jørgensen <toke@...hat.com>, Viktor Malik <vmalik@...hat.com> Subject: Re: [RFC bpf-next 00/16] bpf: Speed up trampoline attach On Fri, Oct 23, 2020 at 09:50:20AM -0400, Steven Rostedt wrote: SNIP > Is there something to keep an eBPF program from tracing a function with 6 > args? If the program saves only 5 args, but traces a function that has 6 > args, then the tracing program may end up using the register that the 6 > argument is in, and corrupting it. > > I'm looking at bpf/trampoline.c, that has: > > arch_prepare_bpf_trampoline(new_image, ...) > > and that new_image is passed into: > > register_ftrace_direct(ip, new_addr); > > where new_addr == new_image. > > And I don't see anywhere in the creating on that new_image that saves the > 6th parameter. arch_prepare_bpf_trampoline ... save_regs(m, &prog, nr_args, stack_size); > > The bpf program calls some helper functions which are allowed to clobber > %r9 (where the 6th parameter is stored on x86_64). That means, when it > returns to the function it traced, the 6th parameter is no longer correct. > > At a minimum, direct callers must save all the parameters used by the > function, not just what the eBPF code may use. > > > > > > > > > The code in question is this: > > > > > > int btf_distill_func_proto(struct bpf_verifier_log *log, > > > struct btf *btf, > > > const struct btf_type *func, > > > const char *tname, > > > struct btf_func_model *m) > > > { > > > const struct btf_param *args; > > > const struct btf_type *t; > > > u32 i, nargs; > > > int ret; > > > > > > if (!func) { > > > /* BTF function prototype doesn't match the verifier types. > > > * Fall back to 5 u64 args. > > > */ > > > for (i = 0; i < 5; i++) > > > m->arg_size[i] = 8; > > > m->ret_size = 8; > > > m->nr_args = 5; > > > return 0; > > > } the fallback code in btf_distill_func_proto you're reffering to is for case of tracing another ebpf program, when hooking to kernel function, all args are used with no fallback to 5 args I'm not sure what are the rules wrt args count when tracing another ebpf program jirka
Powered by blists - more mailing lists