[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.0902222317510.18221@gandalf.stny.rr.com>
Date: Sun, 22 Feb 2009 23:29:09 -0500 (EST)
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
cc: Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
Rusty Russell <rusty@...tcorp.com.au>,
"H. Peter Anvin" <hpa@...or.com>,
Steven Rostedt <srostedt@...hat.com>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists