* Linus Torvalds (torvalds@linux-foundation.org) wrote:
quoted text
> 
> 
> On Fri, 25 Apr 2008, Mathieu Desnoyers wrote:
> > 
> > The point is to provide a way to dynamically enable code at runtime
> > without noticeable performance impact on the system.
> 
> Quite frankly, maybe I'm a bit dense, but why don't you just recompile the 
> whole original function (at run-time), load that new version of a function 
> as a mini-module, and then insert a marker at the top of the old function 
> that just does a "jmp replacementfunction".
> 
> That has _zero_ cost for the non-marker case, and allows you to do pretty 
> much any arbitrary code changes for the marker case.
> 
> It's also a much simpler replacement.
> 

This idea has been considered a few years ago at OLS in the tracing BOF
if I remember well.  The results were this : First, there is no way to
guarantee that no code path, nor any return address from any function,
interrupt, sleeping thread, will return to the "old" version of the
function. Nor is it possible to determine when a quiescent state is
reached. Therefore, we couldn't see how we can do the teardown.

The second point is dependency between execution flow and variables. If
we don't do a complete copy of the variables (which I don't see how we
can do atomically), we will have to share the variables between the old
and the new copies of the functions. However, some variables might
encode information about the execution flow of the program and depend on
the actual address at which the code is linked (function pointers for
instance). Stuff like "goto *addr" would also break.


quoted text
> Yeah, that "jmp replacementfunction" is five or more bytes, but you can 
> trivially do the actual _replacement_ write by writing it first as a 
> single-byte debug trap, and after that has been written, write the target 
> address after it, and then write the first byte of the "jmp" instruction 
> last. In the (very unlikely) case that another CPU hits that debug trap, 
> you just fix it up in the debug handler - you only need a single datum of 
> "this is where that debug trap should relocate", because you simply create 
> a triial spinlock around the code-sequence that does the instruction 
> rewrite.
> 

That's actually what I do in my immediate values implementation.

quoted text
> When undoing it, just do the same thing in reverse.
> 
> Yeah, this requires you to basically recompile some function snippet when 
> you insert a probe, but if that scares people, you could basically do it 
> using the old code and inserting the markers and "relinking" it - avoiding 
> the C compiler, and just basically have an "assembly recompiler".
> 
> And yeah, maybe you want to do without the use of modules, and you'd just 
> have a memory area that is kept free for these kinds of code replacement 
> issues. And you can optimize it to not recompile the whole function, but 
> do it on a finer granularity if you want.
> 

Then dealing with multiple code patching infrastructures (kprobes,
alternatives, paravirt) would become hellish. If a kprobe is planted in
the original version of the function, we have to insert it in the new
version... and the teardown of the old function is still a problem.

quoted text
> And sure, you want to really make sure that there is security in place so 
> that this isn't used for rootkits, but isn't that true of pretty much 
> *any* trace facility?
> 

Yep.

The discussion I refer to took place at OLS a few years ago. Other
participants might remember some other details I forgot.

Mathieu

quoted text
> 			Linus

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/