Displaying 10 results from an estimated 10 matches for "kprobe_blacklist".
2013 Nov 20
0
[PATCH -tip v3 02/23] kprobes: Introduce NOKPROBE_SYMBOL() macro for blacklist
...ar
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...
2013 Nov 08
4
[PATCH -tip RFC 0/2] kprobes: introduce NOKPROBE_SYMBOL() and prohibit probing on .entry.text
...r 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...
2013 Nov 08
4
[PATCH -tip RFC 0/2] kprobes: introduce NOKPROBE_SYMBOL() and prohibit probing on .entry.text
...r 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...
2013 Nov 20
28
[PATCH -tip v3 00/23] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
...y 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...
2013 Nov 20
28
[PATCH -tip v3 00/23] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
...y 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...
2013 Nov 15
23
[PATCH -tip RFC v2 00/22] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
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
2013 Nov 15
23
[PATCH -tip RFC v2 00/22] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
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
2013 Nov 15
0
[PATCH -tip RFC v2 01/22] kprobes: Prohibit probing on .entry.text code
...et)
-/*
- * End of kprobes section
- */
- .popsection
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index a0d367a..ec0dbc7 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -96,9 +96,6 @@ static raw_spinlock_t *kretprobe_table_lock_ptr(unsigned long hash)
static struct kprobe_blackpoint kprobe_blacklist[] = {
{"preempt_schedule",},
{"native_get_debugreg",},
- {"irq_entries_start",},
- {"common_interrupt",},
- {"mcount",}, /* mcount can be called from everywhere */
{NULL} /* Terminator */
};
@@ -1328,8 +1325,11 @@ static int __kprobes in...
2013 Nov 27
1
[PATCH -tip v3 02/23] kprobes: Introduce NOKPROBE_SYMBOL() macro for 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
2013 Nov 27
1
[PATCH -tip v3 02/23] kprobes: Introduce NOKPROBE_SYMBOL() macro for 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