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: Mon, 1 Aug 2022 14:44:47 -0300 From: Arnaldo Carvalho de Melo <acme@...nel.org> To: Daniel Borkmann <daniel@...earbox.net> Cc: Jiri Olsa <jolsa@...nel.org>, Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>, linux-perf-users@...r.kernel.org, netdev@...r.kernel.org, bpf@...r.kernel.org, Ingo Molnar <mingo@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Martin KaFai Lau <kafai@...com>, Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>, John Fastabend <john.fastabend@...il.com>, Ian Rogers <irogers@...gle.com> Subject: Re: [PATCHv5 bpf-next 1/1] perf tools: Rework prologue generation code Em Mon, Jun 20, 2022 at 02:43:22PM +0200, Daniel Borkmann escreveu: > On 6/16/22 10:22 PM, Jiri Olsa wrote: > > Some functions we use for bpf prologue generation are going to be > > deprecated. This change reworks current code not to use them. > > > > We need to replace following functions/struct: > > bpf_program__set_prep > > bpf_program__nth_fd > > struct bpf_prog_prep_result > > > > Currently we use bpf_program__set_prep to hook perf callback before > > program is loaded and provide new instructions with the prologue. > > > > We replace this function/ality by taking instructions for specific > > program, attaching prologue to them and load such new ebpf programs > > with prologue using separate bpf_prog_load calls (outside libbpf > > load machinery). > > > > Before we can take and use program instructions, we need libbpf to > > actually load it. This way we get the final shape of its instructions > > with all relocations and verifier adjustments). > > > > There's one glitch though.. perf kprobe program already assumes > > generated prologue code with proper values in argument registers, > > so loading such program directly will fail in the verifier. > > > > That's where the fallback pre-load handler fits in and prepends > > the initialization code to the program. Once such program is loaded > > we take its instructions, cut off the initialization code and prepend > > the prologue. > > > > I know.. sorry ;-) > > > > To have access to the program when loading this patch adds support to > > register 'fallback' section handler to take care of perf kprobe programs. > > The fallback means that it handles any section definition besides the > > ones that libbpf handles. > > > > The handler serves two purposes: > > - allows perf programs to have special arguments in section name > > - allows perf to use pre-load callback where we can attach init > > code (zeroing all argument registers) to each perf program > > > > Suggested-by: Andrii Nakryiko <andrii@...nel.org> > > Signed-off-by: Jiri Olsa <jolsa@...nel.org> > > Hey Arnaldo, if you get a chance, please take a look. Sry, applied. - Arnaldo
Powered by blists - more mailing lists