Messages in this thread | | | Date | Sun, 22 Feb 2009 23:29:09 -0500 (EST) | From | Steven Rostedt <> | Subject | Re: [PATCH 4/6] ftrace, x86: make kernel text writable only for conversions |
| |
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
| |