| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Not the best solution
Not the best solution
Posted Feb 3, 2005 19:24 UTC (Thu) by bronson (subscriber, #4806)In reply to: Not the best solution by Ross
Parent article: Address space randomization in 2.6
Stack randomization makes BUGGY programs non-deterministic. But then, so does running the program on a different platform. I don't understand your complaint. If you're that worried, just turn randomization off on your development machine.
Aren't canaries a relatively large performance hit? I've written some inner loops that would definitely notice the time needed to generate the canary and check it every time you call a subroutine.
(Log in to post comments)
Not the best solution
Posted Mar 10, 2005 3:47 UTC (Thu) by Ross (subscriber, #4065) [Link]
(I know I'm following up very late so you are probably not going to seethis. But a newer article linked to this and I ran across your post.)
Not only buggy programs but any program that uses "%p" for example. And
the case I was thinking about was specifically dealing with buggy code:
it is nice to be able to reproduce crashes by providing the same inputs to
the program and re-running it if for no other reason that to verify the bug
before submitting a report.
Not the best solution
Posted Jun 25, 2006 0:53 UTC (Sun) by bluefoxicy (guest, #25366) [Link]
Dude, if you jump around bad in randomized code with addresses shifting about every time you start the program over again, you're going to have weird results-- mainly, the program hits bad instructions or unmapped areas and crashes. The more randomization, the more crashes you get.
When not randomizing, sometimes you'll run across something that screws with memory badly for a while; turns your window orange; halts it; produces strange noises; and crashes in some other object file entirely. For example a heap buffer overflow, that can get the heap manager (C library, libc) to try to alter "allocator information" in random memory addresses (hence, double-frees, heap overflows, etc as security attacks). This might not crash the program in certain cases; but if you randomize the address space, then those certain cases will certainly crash the program in one run or another.