OpenBSD Journal

malloc() Guard Pages

Contributed by jose on from the breaking-more-software dept.

A new feature has been added to OpenBSD-current, malloc() guard pages. These can help you debug software and also add some measure of security. From the commit log: 
CVSROOT:      /cvs
Module name:  src
Changes by:   tedu@cvs.openbsd.org    2003/10/16 11:05:05

Modified files:
      lib/libc/stdlib: malloc.3 malloc.c
Log message:
by popular demand, malloc guard pages.  insert an unreadable/unwriteable
page after each page size allocation to detect overrun.  this is
somewhat electric fence like, while attempting to be mostly usable in
production.  also, use tdeval's chunk randomization code.
enabled with the G option.
ok deraadt and co.
People have been testing this on OpenBSD for a while now and fixing various bugs they found, and a few more may lurk. It's configurable with a new malloc.conf(5) option, as opposed to defaulting to "on." Thanks, Ted, for this checkin.

(Comments are closed)

Comments

  1. By Frank Denis () j@pureftpd.org on http://www.skymobile.com/

    Why not enable this by default ?

    May it break valid apps or introduce a significant decrease of performances ?

    Comments

    1. By Anonymous Coward () on

      Why not default? This is an awfull hack in place of proper bounds chekking. How could this break something? If this brakes something it was already broken.

      Comments

      1. By Brad () brad at comstyle dot com on mailto:brad at comstyle dot com

        Yes technically it was "broken" but not in the sense that it will not run at all or crash durring operation.

      2. By tedu () on

        yes, it was broken before, but at least it still worked. end users tend to divide software into working and not working, as opposed to a developer's more philosophical broken and not broken categories. :)

        Comments

        1. By Anthony () on

          "end users"

          I'm not sure you could call OpenBSD users with -current standard end users. I can only speak for myself, but a program that's broken is better segfaulting now than being exploitable later.

          Comments

          1. By Anonymous Coward () on

            no, but -current becomes the next release. I doubt OpenBSD is willing to change it for -release, then back for -current.

    2. By Michael () on

      It looks like this is a 'beta' kind of thing. If you can risk it, enable it and test it out, report bugs, etc.

      The above poster is correct, if this breaks something, then it was already broken.

    3. By Anonymous Coward () on

      Because some shitty software is essential. Try running Mozilla with this...

      Comments

      1. By Brad () brad at comstyle dot com on mailto:brad at comstyle dot com

        That just gives more reason to enable it by default so this shit software can be weeded out.

    4. By Brad () brad at comstyle dot com on mailto:brad at comstyle dot com

      We can only take so much of a performance hit from all of these various features and AFAIK the bugs found from this are not show stoppers.

    5. By tedu () on

      i think performance is acceptable with it. it does waste a fair amount of VM (only actual RAM in some cases). mainly, a make build on sparc64 (which uses large pages and more memory to compile) runs into limit issues. crank before attempting.

      a lot of broken software has already been found, by only a few people testing. defaulting to on would suddenly increase exposure, and it would be a lot of people who perhaps don't understand what happened and would blame openbsd. "mozilla worked before, why'd you break it?" see, it's mozilla that's broken, but that's hard to explain sometimes.

  2. By David Krause () david@openbsd.org on mailto:david@openbsd.org

    Bugs were found in the following software with the aid of guard pages:

    src: csh, cvs, ksh, libcurses, make, sort, tsort
    ports: bison, fetchmail, t1lib
    XF4: freetype

    Please help us find more. If you don't mind living a little dangerously, install or upgrade to the latest -current and 'ln -s AJFG /etc/malloc.conf'. I'm sure that there are more bugs lurking, especially in the ports tree.

    Comments

    1. By David Krause () david@openbsd.org on mailto:david@openbsd.org

      Missed a few:

      src: csh, cvs, ksh, libcurses, make, sed, sort, tsort, whois
      ports: bison, fetchmail, t1lib
      XF4: freetype, xterm

    2. By Pablo Méndez () on

      Hi David:

      F option ? I don't find it in manpage :(

  3. By Janne Johansson () on

    I mean, they actually claim to have whispered code fragments under the door at 5am in the hotel where Theo slept after having a couple of beers with Sir Puffy of Ramsey. The hatemails will surely kill this project now. ;-)

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