search for: _kprobe_blacklist

...+#define __NOKPROBE_SYMBOL(fname) \ > +static struct kprobe_blackpoint __used \ > + _kprobe_bp_##fname = { \ > + .name = #fname, \ > + .start_addr = (unsigned long)fname, \ > + }; \ > +static struct kprobe_blackpoint __used \ > + __attribute__((section("_kprobe_blacklist"))) \ > + *_p_kprobe_bp_##fname = &_kprobe_bp_##fname; 'kprobe_blackpoint' sounds a bit weird - how about 'kprobe_blacklist_entry' ? also, _kprobe_blacklist probably wants to be _kprobes_blacklist, right? Thanks, Ingo

...+#define __NOKPROBE_SYMBOL(fname) \ > +static struct kprobe_blackpoint __used \ > + _kprobe_bp_##fname = { \ > + .name = #fname, \ > + .start_addr = (unsigned long)fname, \ > + }; \ > +static struct kprobe_blackpoint __used \ > + __attribute__((section("_kprobe_blacklist"))) \ > + *_p_kprobe_bp_##fname = &_kprobe_bp_##fname; 'kprobe_blackpoint' sounds a bit weird - how about 'kprobe_blacklist_entry' ? also, _kprobe_blacklist probably wants to be _kprobes_blacklist, right? Thanks, Ingo

...lar to the EXPORT_SYMBOL, put the NOKPROBE_SYMBOL(function); just after the function definition. If CONFIG_KPROBES=y, the macro is expanded to the definition of a static data structure of kprobe_blackpoint which is initialized for the function and put the address of the data structure in the "_kprobe_blacklist" section. Since the data structures are not fully initialized by the macro (because there is no "size" information), those are re-initialized at boot time by using kallsyms. Changes from previous version: - Rename in_nokprobes_functions to within_kprobe_blacklist and it return...

...or the symbols which is listed in kprobes.c. As we discussed in previous thread, if the gcc accepts to introduce new annotation to store the function address (and size) at somewhere, we can easily move onto that by replacing NOKPROBE_SYMBOL() with nokprobe annotation (and just modifying the populate_kprobe_blacklist() a bit). This series also includes a change which prohibits probing on the address in .entry.text because the code is used for very low-level sensitive interrupt/syscall entries. Probing such code may cause unexpected result (actually most of that area is already in the kprobe blacklist). So I...

...or the symbols which is listed in kprobes.c. As we discussed in previous thread, if the gcc accepts to introduce new annotation to store the function address (and size) at somewhere, we can easily move onto that by replacing NOKPROBE_SYMBOL() with nokprobe annotation (and just modifying the populate_kprobe_blacklist() a bit). This series also includes a change which prohibits probing on the address in .entry.text because the code is used for very low-level sensitive interrupt/syscall entries. Probing such code may cause unexpected result (actually most of that area is already in the kprobe blacklist). So I...

...-decompression code to make sure all pointers are correctly > > > initialized. > > I need to check the whole series, but as far as I can understand from > this patch, this seems not allowing to store the address value in > static pointers. It may break more things, for example _kprobe_blacklist > records the NOKPROBE_SYMBOL() symbol addresses at the build time. The runtime-initialization function is only used in the pre-decompression boot code (arch/x86/boot/compressed/) which is not part of the running kernel image. At that stage of booting there is no support for kprobe or tracing o...

...dy in the kprobe blacklist). So I've decide to prohibit probing all of them. Finally, I got an empty .kprobes.text on x86 :) $ grep kprobes_text System.map ffffffff81604980 T __kprobes_text_end ffffffff81604980 T __kprobes_text_start Thank you, Changes from v2 to v3: - Introduce arch_within_kprobe_blacklist() which checks the address is within the .kprobes.text (generic,x86) or .entry.text (x86), for fixing build issue on !x86. - Rename in_nokprobes_functions to within_kprobe_blacklist and it returns a bool value istead of an error. - Fix the type of kprobe_blacklist_seq_stop(). - Use blac...

...dy in the kprobe blacklist). So I've decide to prohibit probing all of them. Finally, I got an empty .kprobes.text on x86 :) $ grep kprobes_text System.map ffffffff81604980 T __kprobes_text_end ffffffff81604980 T __kprobes_text_start Thank you, Changes from v2 to v3: - Introduce arch_within_kprobe_blacklist() which checks the address is within the .kprobes.text (generic,x86) or .entry.text (x86), for fixing build issue on !x86. - Rename in_nokprobes_functions to within_kprobe_blacklist and it returns a bool value istead of an error. - Fix the type of kprobe_blacklist_seq_stop(). - Use blac...

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series