OpenBSD Journal

omalloc improvements

Contributed by ray on from the stomping-out-bugs-one-byte-at-a-time dept.

Otto Moerbeek (otto@) just committed two changes to make his malloc(3) stricter, to better shake out bugs. Together, these can catch buffer overflows of even one byte.
CVSROOT:	/cvs
Module name:	src
Changes by:	otto@	2008/11/20 02:01:24

Modified files:
	lib/libc/stdlib: malloc.c 

Log message:
Reduce the leeway malloc allows when moving allocations to the end of
a page to 0. P default will be changed in a separate commit.
ok millert@ art@ krw@

CVSROOT: /cvs Module name: src Changes by: otto@ 2008/11/20 02:05:15 Modified files: lib/libc/stdlib: malloc.3 malloc.c Log message: move allocations between half a page and a page as close to the end of the page as possible (i.e. make malloc option P a default). ok art@ millert@ krw@
Be sure to report any programs that are suddenly crashing, preferably with a fix! =)

(Comments are closed)


Comments
  1. By Anonymous Coward (76.94.214.186) on

    Awesome stuff. Thanks!

  2. By Anonymous Coward (85.19.213.88) on

    Is this already in the snapshots? It's not always clear to me when something is in snapshots and when you have to apply the diff and compile yourself. Is there some "rule" or something that I'm missing that would make these things obvious?

    Comments
    1. By Anonymous Coward (85.19.213.88) on

      > Is this already in the snapshots? It's not always clear to me when
      > something is in snapshots and when you have to apply the diff and
      > compile yourself. Is there some "rule" or something that I'm missing
      > that would make these things obvious?

      Replying to myself: obviously this will be in any snapshot after 2008-11-20 since it was committed. In general, though, I think my question is still valid.

      Comments
      1. By Matt (67.173.91.74) on

        I think if it's been committed to current it's automatically in snapshots, but the snapshots might have extra patches that haven't yet been committed to current.

  3. By Anonymous Coward (79.15.190.90) on

    Anyone who says that they don't want otto@'s love child after this is lying.

    Comments
    1. By Miod Vallat (miod) on

      > Anyone who says that they don't want otto@'s love child after this is lying.

      Don't force Marie-Josť to kill you.

  4. By Anonymous Coward (82.101.210.49) on

    Together, these can catch buffer overflows of even one byte.

    So does that mean that now all buffer overflows will be caught, or just that more will be caught?

    Comments
    1. By Wouter (82.95.152.15) on

      > So does that mean that now all buffer overflows will be caught, or just that more will be caught?

      No, this only works for allocations from half a page up to a page in size, so on i386 typically between 2048 and 4096 bytes. If I understand correctly, smaller structures are still allocated normally because otherwise this would use op way too much memory.

      Comments
      1. By Otto Moerbeek (otto) on http://www.drijf.net

        > No, this only works for allocations from half a page up to a page in size, so on i386 typically between 2048 and 4096 bytes. If I understand correctly, smaller structures are still allocated normally because otherwise this would use op way too much memory.

        Right. Additionally, alignment constraints also cause the end of the buffer to not always be the end of a page. Also, the next page might or might not be mapped. Because we have random page allocations, chances are pretty high the next page will not be mapped, and accessing it wil cause a segmentation violation.

        In case you are wondering, objects equal or larger than a page are page aligned to be able to call mprotect(2) and friends on them.

        -Otto


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