Text 6771, 101 rader
Skriven 2005-08-28 09:39:10 av Mike '/m' (1:379/45)
   Kommentar till text 6757 av Rich (1:379/45)
Ärende: Re: malloc() and free() redux
=====================================
From: Mike '/m' <mike@barkto.com>


Have fun spinning, Rich.


On Sat, 27 Aug 2005 18:22:15 -0700, "Rich" <@> wrote:

>   According to you his interest is asking other people to do the work for
which he is not doing something to make it easy.  Seems like a copout to me.
Not that any of this will change your claimed opinions.
>
>Rich
>
>  "Mike '/m'" <mike@barkto.com> wrote in message
news:qdj1h1tmqmpl5fop0km2s8g4jhl6sbqfso@4ax.com...
>
>  Yup, Mr. Deraadt is keen on improving software quality.
>
>  Unlike Bill Gates who said, "If you can't make it good, make it look
>  good."
>
>
>    /m
>
>  On Sat, 27 Aug 2005 11:38:03 -0700, "Rich" <@> wrote:
>
>  >   What I found significant about your quote is that it ends with the
following appeal.  It is clear he wants such problems found.  It is silly to
expect this but not to make an effort to make this easy.
>  >
>  >  We ask our users to help us uncover and fix more of these bugs in
>  >  applications.  Some will even be exploitable.  Instead of saying that
>  >  OpenBSD is busted in this regard, please realize that the software
>  >  which is crashing is showing how shoddily it was written.  Then help
>  >  us fix it.  For everyone.. not just OpenBSD users
>  >
>  >You misunderstand if you believe buffer overflows and underflows won't run
into other data.  First, this is for the heap not for the stack.  Both are
dangerous but stack overflows are probably still more common.  Second, memory
is allocated in units of at least a page and probably larger units.  Most
allocations are preceeded and followed by other allocations.
>  >
>  >Rich
>  >
>  >
>  >  "Mike '/m'" <mike@barkto.com> wrote in message
news:3l61h19q3gjomo2jtvs3td7cri8ajgs95i@4ax.com...
>  >  I see the malloc/free improvements as more for runtime benefit, i.e.,
>  >  buffer overflow exploits and such.  Exploits won't be able to use memory
>  >  addresses as easily as before, because malloc randomizes them at
>  >  runtime, buffer underflow/overflow exploits run into out-of-process
>  >  memory and not the next variable, etc.  Mr. DeRaadt's message explains
>  >  quite a bit about the runtime aspect of the enhancements.
>  >
>  >  There are other open source tools for developers that do what you
>  >  suggest.  The paragraph you quote indicates that more developers should
>  >  use those tools, and that the new runtime enhancements will make such
>  >  errors easier to track down.
>  >
>  >   /m
>  >
>  >
>  >  On Sat, 27 Aug 2005 09:05:34 -0700, "Rich" <@> wrote:
>  >
>  >  >   OK.  They can continue to find issues with luck at random.  Why make
any effort to increase quality?
>  >  >
>  >  >Rich
>  >  >
>  >  >  "Mike '/m'" <mike@barkto.com> wrote in message
news:50q0h1tf5m86ehvd13p849uq42pdsqu45v@4ax.com...
>  >  >
>  >  >  MRD
>  >  >
>  >  >  On Fri, 26 Aug 2005 22:09:56 -0700, "Rich" <@> wrote:
>  >  >
>  >  >  >   For many years Windows has had mechanisms to force unmap after
free, guard pages, and the like to make it easier for developers to catch heap
overruns, use after free, double free, etc.  If the openbsd folks were smart
they would do the same.
>  >  >  >
>  >  >  >Rich
>  >  >  >
>  >  >  >  "Mike '/m'" <mike@barkto.com> wrote in message
news:5ldvg1tlt8qietjcqrt0jakcnukm5sp7it@4ax.com...
>  >  >  >
>  >  >  >
>  >  >  >  We expect that our malloc will find more bugs in software, and this
>  >  >  >  might hurt our user community in the short term.  We know that what
>  >  >  >  this new malloc is doing is perfectly legal, but that realistically
>  >  >  >  some open source software is of such low quality that it is just
not
>  >  >  >  ready for these things to happen.
>  >  >  >
>  >  >  >  ===
>  >  >  >
>  >  >  >    /m

--- BBBS/NT v4.01 Flag-5
 * Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)