Re: [PATCH 1/5] ftrace: Synchronize variable setting withbreakpoints

[Steven Rostedt]

On Thu, 2012-05-31 at 15:55 -0400, Mathieu Desnoyers wrote:

> > Also, why did Mathieu insist on keeping that kmap()?
> 
> Not sure about the entire context here, but the goal of using kmap() is
> to allow modification of text in configurations where the kernel text
> is read-only: the kmap does a temporary shadow RW mapping that allows
> modification of the text. Presumably that Ftrace's 30k changes are done
> before the kernel text mapping is set to read-only ? If this is the
> case, then it is similar to text_poke_early, which don't use the kmap
> since it happens before kernel text gets write-protected. But text_poke
> has to deal with RO pages.

No this is also when ftrace is enabled at runtime. The trick that ftrace
does is to temporarially  convert the kernel text from ro to rw, and
then back to ro when done. You can argue that this degrades the security
of the system, but tracing every function in the kernel does too ;-)
That's why it's a root only utility.

Hmm, this brings up another question. By default, perf does not allow
users to profile trace_events correct? IOW, perf does not let
unprivileged users call text_poke()? I just tried it and got the:

$ ~/bin/perf record -e sched:sched_switch sleep 1
Permission error - are you root?
Consider tweaking /proc/sys/kernel/perf_event_paranoid:
 -1 - Not paranoid at all
  0 - Disallow raw tracepoint access for unpriv
  1 - Disallow cpu events for unpriv
  2 - Disallow kernel profiling for unpriv


> 
> Hopefully my answer makes sense in the context of your discussion.

Almost,

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/