checking /proc/sys/kernel/ftrace_enabled #1152
Conversation
8506db8 to
892e892
Compare
this goes in the PR body, not title :) |
|
In the linked issue you say you will add the check to libbpfgo, what changed? |
|
Yes, @mtcherni95 , please check: |
|
I will update PR by using helper in libbpfgo - this will require update of go mod version of libbpgo |
|
@mtcherni95 Now that we've upgraded the libbpfgo dependency to the latest release (which includes this helper function) you can update this PR. |
892e892 to
6114c91
Compare
great, thanks a lot! |
6114c91 to
005d4cd
Compare
tracee-ebpf/main.go
Outdated
| if err != nil { | ||
| return err | ||
| } | ||
| if !enabled { | ||
| fmt.Fprintf(os.Stderr, "ftrace_enabled: warning: ftrace is not enabled - kprobes won't be inserted\n") |
There was a problem hiding this comment.
To a user, I don't know if having "kprobes won't be inserted" is very useful. Is it possible to list events that won't be traced? Are we sure that ftrace is absolutely required for all kprobes?
There was a problem hiding this comment.
I think so yeah. @yanivagman ?
There was a problem hiding this comment.
Ftrace is needed for kprobes as they're built on top of ftrace base architecture (https://www.kernel.org/doc/Documentation/trace/ftrace-design.txt & https://www.kernel.org/doc/Documentation/trace/kprobetrace.txt), like an extension to it. I don't think we should expand to much here, but I do think the message could be clearer for an average user that might not know what kprobes and ftrace are.
There was a problem hiding this comment.
I actually think that if a user is using Tracee then most likely he will have some technical background (and kprobes knowledge as well). I suggest something like "ftrace_enabled: warning: ftrace is not enabled - some events may not be caught (kprobes not enabled)".
There was a problem hiding this comment.
I believe no events, at all, will be caught, if ftrace is disabled.
And I disagree that users of tracee will know what a kprobe (or ftrace) is.
I do agree that a warning like that could be helpful as long as it is rephrased to something like:
ftrace_enabled: warning: ftrace is not enabled, kernel events won't be caught, make sure to enable it by executing echo 1 | sudo tee /proc/sys/kernel/ftrace_enabled
There was a problem hiding this comment.
You do get events coming from tracepoints.
Let's go with your message then :)
There was a problem hiding this comment.
You do get events coming from tracepoints.
I see what you mean. But our ebpf logic might be broken as there are maps manipulated by different eBPF programs (with different probe methods) in different times, I believe.
I agree that if we consider tracee purely as an introspection tool, final user might know what we're talking about... but we're trying to shift that mindset as well (thus the explicit message about how to get it enabled).
Cool, thanks.
There was a problem hiding this comment.
So if this is the case should we just error out if ftrace is disabled? Is there any point in running tracee?
There was a problem hiding this comment.
So if this is the case should we just error out if ftrace is disabled? Is there any point in running tracee?
I don't think so - tracepoint will still work, which means that all the syscalls + some other events will still work (> 95% of the events are not kprobes) - so I think we should just warn
There was a problem hiding this comment.
Alright then, works for me.
005d4cd to
2eda2b3
Compare
Resolves: #1150