Summary: | Probes on "__kprobes" functions should not be allowed | ||
---|---|---|---|
Product: | systemtap | Reporter: | Josh Stone <jistone> |
Component: | translator | Assignee: | Unassigned <systemtap> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: |
Proposed patch
Improved patch |
Description
Josh Stone
2006-05-04 00:16:29 UTC
Just to clarify - the kprobes runtime correctly blocks probes within the .kprobes.text section, so this isn't a stability issue. The user will see this get all the way to pass-5, and then it will fail to register the probe. It would be nicer if we could catch this earlier, probably in the blacklist check like we do with __init and __exit. For now, I've manually added all __kprobes functions to the translator blacklist. This won't prevent statement() probes from being requested within these functions, but it's better than nothing. The kprobes infrastructure will still reject such probes at runtime if any slip through. (tapsets.cxx r1.131) Created attachment 1361 [details]
Proposed patch
This proposed patches mimics the kernel function "in_kprobes_functions" by
looking up the value of the symbols "__kprobes_text_start" and
"__kprobes_text_end" and makes sure a probe point address isn't between those
two values.
Created attachment 1364 [details]
Improved patch
This improved patch moves the static '__kprobes_text_start' and
'__kprobes_text_end' variables into the session object.
Patch should allow us to reject all addresses within functions marked as '__kprobes'. |