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: Sat, 15 Jan 2022 13:39:07 +0900 From: Masami Hiramatsu <mhiramat@...nel.org> To: Jiri Olsa <jolsa@...hat.com> Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, netdev@...r.kernel.org, bpf@...r.kernel.org, lkml <linux-kernel@...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>, Steven Rostedt <rostedt@...dmis.org>, "Naveen N . Rao" <naveen.n.rao@...ux.ibm.com>, Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>, "David S . Miller" <davem@...emloft.net> Subject: Re: [RFC PATCH v2 3/8] rethook: Add a generic return hook On Fri, 14 Jan 2022 16:18:13 +0100 Jiri Olsa <jolsa@...hat.com> wrote: > On Thu, Jan 13, 2022 at 10:15:32PM +0900, Masami Hiramatsu wrote: > > On Thu, 13 Jan 2022 13:25:52 +0100 > > Jiri Olsa <jolsa@...hat.com> wrote: > > > > > On Wed, Jan 12, 2022 at 11:03:22PM +0900, Masami Hiramatsu wrote: > > > > Add a return hook framework which hooks the function > > > > return. Most of the idea came from the kretprobe, but > > > > this is independent from kretprobe. > > > > Note that this is expected to be used with other > > > > function entry hooking feature, like ftrace, fprobe, > > > > adn kprobes. Eventually this will replace the > > > > kretprobe (e.g. kprobe + rethook = kretprobe), but > > > > at this moment, this is just a additional hook. > > > > > > this looks similar to the code kretprobe is using now > > > > Yes, I've mostly re-typed the code :) > > > > > would it make sense to incrementaly change current code to provide > > > this rethook interface? instead of big switch of current kretprobe > > > to kprobe + new rethook interface in future? > > > > Would you mean modifying the kretprobe instance code to provide > > similar one, and rename it at some point? > > My original idea is to keep the current kretprobe code and build > > up the similar one, and switch to it at some point. Actually, > > I don't want to change the current kretprobe interface itself, > > but the backend will be changed. For example, current kretprobe > > has below interface. > > > > struct kretprobe { > > struct kprobe kp; > > kretprobe_handler_t handler; > > kretprobe_handler_t entry_handler; > > int maxactive; > > int nmissed; > > size_t data_size; > > struct freelist_head freelist; > > struct kretprobe_holder *rph; > > }; > > > > My idea is switching it to below. > > > > struct kretprobe { > > struct kprobe kp; > > kretprobe_handler_t handler; > > kretprobe_handler_t entry_handler; > > int maxactive; > > int nmissed; > > size_t data_size; > > struct rethook *rethook; > > }; > > looks good, will this be a lot of changes? Yes and no, we can easily replace the kretprobe generic trampoline callback (since it almost same, and have same feature), but it also needs to update per-arch kretprobe trampoline to rethook trampoline. > could you include it in the patchset? Let me try, but since it involves many archs (which support kretprobes) it may take a time to be merged. Thank you, > > thanks, > jirka > > > > > Of course 'kretprobe_instance' may need to be changed... > > > > struct kretprobe_instance { > > struct rethook_node; > > char data[]; > > }; > > > > But even though, since there is 'get_kretprobe(ri)' wrapper, user > > will be able to access the 'struct kretprobe' from kretprobe_instance > > transparently. > > > > Thank you, > > > > > > -- > > Masami Hiramatsu <mhiramat@...nel.org> > > > -- Masami Hiramatsu <mhiramat@...nel.org>
Powered by blists - more mailing lists