|
From: Sebastian B. <sb...@bi...> - 2004-08-30 19:18:08
|
Hi! Now that the timer code works (thanks for the fast responses!), I have a problem with valgrind itself. The program I work on is also a JIT[1], so it could also be an obscure prefetch queue problem or so, but the program definitely behaves differently when being valgrinded. (I read the "Limitations" section of the documentation, and found nothing that valgrind can't handle self-modifying code, so I assume it can.) Since my JIT has the nice property, that I can run the translated code and a slower interpreter concurrently and compare the results after each instruction, I was able to spot the problem -- but I don't understand how the code in question could ever be misinterpreted. On this http://developer.kde.org/~sewardj/docs-2.1.2/mc_techdocs.html#mc-techdocs page I saw some nice debug output of the translated code of valgrind. Is there a runtime option (like the VALGRIND_XXX macros) to conditionally turn on this debugging output when my program gets near the suspicious code? Or should I use the "--stop-after=" method to narrow down to the BB in question? Sebastian -- [1] PearPC, http://pearpc.sf.net |
|
From: Nicholas N. <nj...@ca...> - 2004-08-30 19:32:00
|
On Mon, 30 Aug 2004, Sebastian Biallas wrote: > Now that the timer code works (thanks for the fast responses!), I have a > problem with valgrind itself. The program I work on is also a JIT[1], so it > could also be an obscure prefetch queue problem or so, but the program > definitely behaves differently when being valgrinded. (I read the > "Limitations" section of the documentation, and found nothing that valgrind > can't handle self-modifying code, so I assume it can.) Hmm, then that section of the manual should be changed. Valgrind can handle dynamically-generated code just fine. However, if you regenerate code over the top of old code (ie. at the same memory addresses) Valgrind will not realise the code has changed, and will run its old translations, which will be out-of-date. So you need to use the VALGRIND_DISCARD_TRANSLATIONS client request in that case. > Since my JIT has the nice property, that I can run the translated code and a > slower interpreter concurrently and compare the results after each > instruction, I was able to spot the problem -- but I don't understand how the > code in question could ever be misinterpreted. Yes, that's a very nice feature to have :) > On this > http://developer.kde.org/~sewardj/docs-2.1.2/mc_techdocs.html#mc-techdocs > page I saw some nice debug output of the translated code of valgrind. Is > there a runtime option (like the VALGRIND_XXX macros) to conditionally turn > on this debugging output when my program gets near the suspicious code? Or > should I use the "--stop-after=" method to narrow down to the BB in question? --stop-after doesn't exist any more, unfortunately. Use --trace-codegen to get the debug output (try --trace-codegen=10000 to begin with). That prints out all the code; if you only want some, you can crudely adjust the point at which code starts being printed via the 'notrace_until_limit' variable in vg_translate.c. HTH N |
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 19:40:20
|
Nicholas Nethercote wrote: > On Mon, 30 Aug 2004, Sebastian Biallas wrote: > >> Now that the timer code works (thanks for the fast responses!), I have >> a problem with valgrind itself. The program I work on is also a >> JIT[1], so it could also be an obscure prefetch queue problem or so, >> but the program definitely behaves differently when being valgrinded. >> (I read the "Limitations" section of the documentation, and found >> nothing that valgrind can't handle self-modifying code, so I assume it >> can.) > > Hmm, then that section of the manual should be changed. Ok, that explains the problem. > > Valgrind can handle dynamically-generated code just fine. However, if > you regenerate code over the top of old code (ie. at the same memory > addresses) Valgrind will not realise the code has changed, and will run > its old translations, which will be out-of-date. So you need to use the > VALGRIND_DISCARD_TRANSLATIONS client request in that case. Don't know if there is much need for it, but it might be possible to make all pages that have PROT_EXEC | PROT_WRITE access read/execute-only and trap writes to these pages to automatically detect the situation. But anyway, I'll test if using VALGRIND_DISCARD_TRANSLATIONS helps. >> Since my JIT has the nice property, that I can run the translated code >> and a slower interpreter concurrently and compare the results after >> each instruction, I was able to spot the problem -- but I don't >> understand how the code in question could ever be misinterpreted. > > > Yes, that's a very nice feature to have :) > >> On this >> http://developer.kde.org/~sewardj/docs-2.1.2/mc_techdocs.html#mc-techdocs >> page I saw some nice debug output of the translated code of valgrind. >> Is there a runtime option (like the VALGRIND_XXX macros) to >> conditionally turn on this debugging output when my program gets near >> the suspicious code? Or should I use the "--stop-after=" method to >> narrow down to the BB in question? > > --stop-after doesn't exist any more, unfortunately. Use --trace-codegen > to get the debug output (try --trace-codegen=10000 to begin with). That > prints out all the code; if you only want some, you can crudely adjust > the point at which code starts being printed via the > 'notrace_until_limit' variable in vg_translate.c. Well, I don't think it's still necessary since my assumption that valgrind can handle the self-modifying code were wrong. > > HTH > > N > Sebastian |
|
From: Nicholas N. <nj...@ca...> - 2004-08-30 19:46:09
|
On Mon, 30 Aug 2004, Sebastian Biallas wrote: > Don't know if there is much need for it, but it might be possible to make all > pages that have PROT_EXEC | PROT_WRITE access read/execute-only and trap > writes to these pages to automatically detect the situation. That would catch some of them. But the problem, AFAICT, with all self-modifying code detection schemes is how to handle code on the stack. For example, GCC generates snippets of code on the stack when using nested functions. N |
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 19:57:17
|
Nicholas Nethercote wrote: > On Mon, 30 Aug 2004, Sebastian Biallas wrote: > >> Don't know if there is much need for it, but it might be possible to >> make all pages that have PROT_EXEC | PROT_WRITE access >> read/execute-only and trap writes to these pages to automatically >> detect the situation. > > That would catch some of them. But the problem, AFAICT, with all > self-modifying code detection schemes is how to handle code on the > stack. For example, GCC generates snippets of code on the stack when > using nested functions. What? I thought this is highly undefined or at least deprecated, and with NX-aware processores and kernels it will no longer work. > > N > Sebastian |
|
From: Nicholas N. <nj...@ca...> - 2004-08-30 20:13:36
|
On Mon, 30 Aug 2004, Sebastian Biallas wrote: >> That would catch some of them. But the problem, AFAICT, with all >> self-modifying code detection schemes is how to handle code on the stack. >> For example, GCC generates snippets of code on the stack when using nested >> functions. > > What? I thought this is highly undefined or at least deprecated, Seemingly not, see http://bugs.kde.org/show_bug.cgi?id=69511. > and with NX-aware processores and kernels it will no longer work. I'm no expert on that stuff, but I believe that GCC just turns off the no-exec functionality in such systems in these cases. Nasty, huh? N |
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 20:46:01
|
Nicholas Nethercote wrote: > On Mon, 30 Aug 2004, Sebastian Biallas wrote: > >>> That would catch some of them. But the problem, AFAICT, with all >>> self-modifying code detection schemes is how to handle code on the >>> stack. For example, GCC generates snippets of code on the stack when >>> using nested functions. >> >> What? I thought this is highly undefined or at least deprecated, > > Seemingly not, see http://bugs.kde.org/show_bug.cgi?id=69511. Indeed, gcc emits "call %esp". > >> and with NX-aware processores and kernels it will no longer work. > > I'm no expert on that stuff, but I believe that GCC just turns off the > no-exec functionality in such systems in these cases. Nasty, huh? Very nasty: http://www.ussg.iu.edu/hypermail/linux/kernel/0406.0/1056.html Yesterdays technology tomorrow. > > N > Sebastian |
|
From: Robert W. <rj...@du...> - 2004-08-30 20:53:34
|
> Indeed, gcc emits "call %esp". Interesting. Could be a way of spotting the problem - just Do Something for that specific call. Regards, Robert. |
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 21:04:54
|
Robert Walsh wrote: >>Indeed, gcc emits "call %esp". > > Interesting. Could be a way of spotting the problem - just Do Something > for that specific call. No, gcc also uses different registers there, depending on optimization level etc. And you have no (real) change to detect this when gcc just passes a pointer to the stack containing code (like in this example). [NB: The "call %esp" in my test was a result of inlining "static void call_func(void (*sel)(void))" from the bug report. It's quite interesting that gcc no longer understands it's own mess after inlining this function, and so is unable to optimize the trampoline code away] > > Regards, > Robert. > > Sebastian |
|
From: Julian S. <js...@ac...> - 2004-08-30 21:13:49
|
> > and with NX-aware processores and kernels it will no longer work. > > I'm no expert on that stuff, but I believe that GCC just turns off the > no-exec functionality in such systems in these cases. Nasty, huh? If the NX functionality is turnable-offable from user-space, how can it have any value as a security enhancement mechanism? /me suspects /me has misunderstood something. J |
|
From: Tom H. <th...@cy...> - 2004-08-30 21:18:29
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> > > and with NX-aware processores and kernels it will no longer work.
> >
> > I'm no expert on that stuff, but I believe that GCC just turns off the
> > no-exec functionality in such systems in these cases. Nasty, huh?
>
> If the NX functionality is turnable-offable from user-space, how can it
> have any value as a security enhancement mechanism?
It can't be turned on and off on the fly, but gcc and the linker
can co-operate to mark an ELF file as needing (or not needing) an
executable stack and the kernel will pay attention to that when
starting the program.
So if you have a program that has an executable stack then it is
protected, but other programs are.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 21:27:30
|
Julian Seward wrote: >>>and with NX-aware processores and kernels it will no longer work. >> >>I'm no expert on that stuff, but I believe that GCC just turns off the >>no-exec functionality in such systems in these cases. Nasty, huh? > > > If the NX functionality is turnable-offable from user-space, how can it > have any value as a security enhancement mechanism? > > /me suspects /me has misunderstood something. The NX feature should harden your application against buffer-overflows[1]. But NX is a protection against remote exploits, not against locale exploits. If an attacker has sucessfully injected (and executed) code into your system, he has already won, there is no need to turn off NX :) And of course you can't switch off NX for files you don't have write access to (it's encoded in the header of the files, not in your ~/.nxconf ;) ). > > J > Sebastian [1] Note that NX without address space randomization is almost useless, but that's another story. |
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 21:33:58
|
Sebastian Biallas wrote: > Nicholas Nethercote wrote: >> On Mon, 30 Aug 2004, Sebastian Biallas wrote: >>>> That would catch some of them. But the problem, AFAICT, with all >>>> self-modifying code detection schemes is how to handle code on the >>>> stack. For example, GCC generates snippets of code on the stack when >>>> using nested functions. >>> >>> What? I thought this is highly undefined or at least deprecated, >> >> Seemingly not, see http://bugs.kde.org/show_bug.cgi?id=69511. > > > Indeed, gcc emits "call %esp". > Slightly off-topic, but I just looked on how gcc does this on powerpc. There gcc calls __trampoline_setup which has to manually invalidate the instruction cache lines. I'm happy that I decided to emulate such a clean processor design :) Sebastian |
|
From: Paul M. <pa...@sa...> - 2004-08-30 23:02:15
|
Sebastian Biallas writes: > Slightly off-topic, but I just looked on how gcc does this on powerpc. > There gcc calls __trampoline_setup which has to manually invalidate the > instruction cache lines. I'm happy that I decided to emulate such a > clean processor design :) Yes, and Valgrind on PowerPC doesn't have any problems with self-modifying code, because when the simulated cpu encounters the icbi (instruction cache block invalidate) instruction, we invalidate any translations that overlap the specified cache line. Essentially, V's translation cache is equivalent to a real processor's instruction cache. Paul. |