Contributed by
todd
on
from the SEGV-is-better-than-the-alternative dept.
The fact that
malloc(3),
the userland's method for allocating memory, has been rewritten to use the
mmap(2)
system call is more than a small step. Traditionally, memory allocated to a system would be all together in one contiguous region. If an algorithm in a program behaved reliably but stepping slightly outside the area of memory it allocated, this was a bug gone undetected. With the release of 3.8, because of the way mmap randomizes the location in memory, this is no longer true.
Since the location is random, `empty space' is between almost every allocation and the next. Stepping in this `empty space' causes a program to segfault, thus making bugs more easy to find. Some people are not happy to find that previously reliable programs suddenly start crashing. However, as one person put it, they would rather have an application crash than introduce a subtle but undetected corruption in some mission critical database that does not get detected until three months down the road. One such application is X(7), the graphics interface for nearly any UNIX based platforms, including Linux, Solaris, and the other BSD distributions. It was discovered that the X server would crash in several different ways. Ultimately, there have been more patches applied for several uniquely different problems than I can count on one hand. This is but one application, and many undetected bugs were fixed because of this one ``not so small change'' to memory allocation in OpenBSD.
Fixing bugs is a very good thing, at the heart of OpenBSD's security track record, because all security issues are bugs, or poorly written code. Once again, another nail in the coffin of bugs everywhere for OpenBSD!
(Comments are closed)
Comments
By
Anonymous Coward (82.43.92.127)
on
Anything that improves reliability of code I use and OpenBSD in general is fine by me :)
Comments
By
Anonymous Coward (213.118.134.107)
on
Is it at all possible to, say, include a new mmap/malloc header file and use it for my day-to-day C programming on a windows box?
Or does the whole thing rely on underlying openbsd-only architectural implementations?
Comments
By
Anonymous Coward (68.18.23.68)
on
The latter, unfortunately.
Comments
By
tedu (71.139.175.127)
on
not entirely true. i'm not sure what the rules are like on windows for replacing malloc, but i've used openbsd's malloc on several other operating systems.
Comments
By
Anonymous Coward (69.232.44.1)
on
but mmap is implemented in the kernel, and it's the random mmap that makes the new mmap based malloc interesting.
Comments
By
tedu (71.139.175.127)
on
like it's not possible to generate random numbers in userland...
By
BasharTeg (68.69.239.52) basharteg@basharteg.com
on
It's certainly possible to emulate this behavior very easily under Windows using random numbers and VirtualAlloc().
By
Janne Johansson (82.182.176.20)
on
www.inet6.se
Wehn this came to snapshots, I tried to see if windows XP would do something similar, and in my tests, you needed to malloc more than 400K in order for free() to acutally free the space. It depends some on if you are running a debug build or release build in VC, but release builds with mallocs less than 400k would still allow you to use the memory after free()ing them. debug builds would also let you touch it, but when run from the debugger, it at least "destroys" the content in free()d spaces so you easier find rogue accesses. Still, it's far from the smallish 4k limit that OpenBSD now imposes on mallocs before they get free for real.
Perhaps someone with patience should test lots of OSes and see where they put their limits?
By Anonymous Coward (82.43.92.127) on
Comments
By Anonymous Coward (213.118.134.107) on
Comments
By Anonymous Coward (68.18.23.68) on
Comments
By tedu (71.139.175.127) on
Comments
By Anonymous Coward (69.232.44.1) on
Comments
By tedu (71.139.175.127) on
By BasharTeg (68.69.239.52) basharteg@basharteg.com on
By Janne Johansson (82.182.176.20) on www.inet6.se
Perhaps someone with patience should test lots of OSes and see where they put their limits?
By Krunch (80.200.227.67) on http://krunch.servebeer.com/~krunch/