On 9 Jan 2007 07:04:11 -0800, sturlamolden <[EMAIL PROTECTED]> wrote: > > Jorgen Grahn wrote: > >> For what it's worth[1], under Unix it /is/ impossible. The only way to bring >> in >> new code (short of dynamic libraries) is to call exec(2) or its variations, >> and all need a file system object to load the code from. > > The x86 processor cannot tell the difference between code segments and > data segments. If the executable code is stored in string, all you need > is a pointer to the string holding the code. You can cast the string > address to a function pointer (possibly through a void* if the compiler > complains), then dereference (call) the function pointer. > > Trojans, viruses and JIT compilers do this all the time. Here is an > (untested) example: [...]
You probably need to flush the code cache somewhere there, too, don't you? Or will that resolve itself because that memory area hasn't been executed before? I must admit I haven't contemplated this since the MC68000 was state of the art, before caches became popular. /Jorgen -- // Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu \X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn! -- http://mail.python.org/mailman/listinfo/python-list
