Re: [PATCH 4/6] ftrace, x86: make kernel text writable only for conversions

[Steven Rostedt <rostedt@goodmis.org>]

On Sun, 22 Feb 2009, Mathieu Desnoyers wrote:
> > 
> > We are changing over 19000 locations in the kernel. This touches almost 
> > all kernel text pages anyway. You want to map a page in and out for over 
> > 19000 locations?
> > 
> > -- Steve
> > 
> 
> Hi Steve,
> 
> Can you provide numbers to indicate why it's required to be so intrusive
> in the kernel mappings while doing these modifications ? I think opening
> such time window where standard code mapping is writeable globally in
> config RO_DATA kernels could open the door to unexpected side-effects,
> so ideally going through the "backdoor" page mapped by text_poke seems
> safer. Given similar performance, I would tend to use a text_poke-like
> approach.
> 

Not sure which numbers you are asking for. The dynamic function tracer 
modifies all mcount calls, which are done by practically every function in 
the kernel. With a normal Fedora kernel (and all its loaded modules), 
that's between 15 to 20 thousand functions, depending on what modules are 
loaded.

At boot up we convert them all to nops, but when we enable the function 
tracer, we convert them back to calls to the function tracer. This is done 
by a priviledge user, since the function tracer can add quite a bit of 
overhead when activated.

I do not really see how changing this for the short period of time is any 
different than making another mapping point to the kernel code. If you 
could find a way to break this security, you should be able to break it 
with another mapping as well.

Also note that this dynamic tracing code works for not only x86, it also 
works for PPC, ARM, superH and ia64. To use text_poke, that would require 
all of these to have text_poke ported.

How does text_poke solve the issue of executing code on another CPU that 
is changing?

-- Steve