OpenBSD Journal

New Feature Alert: mmap(2) malloc(3)

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

  1. 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

    1. 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

      1. By Anonymous Coward (68.18.23.68) on

        The latter, unfortunately.

        Comments

        1. 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

          1. 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

            1. By tedu (71.139.175.127) on

              like it's not possible to generate random numbers in userland...

            2. 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().

      2. 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?

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]