Andrew Morton <andrewm@uow.edu.au> writes:
> "Michael H. Warfield" wrote:
> >
> > Have you seen the new release from Bell labs? Here's another
> > twist to out foxing the buffer overruns.
> >
> > http://www.bell-labs.com/news/2000/april/20/1.html
> >
> > I suspect that this isn't a silver bullet either but it looks like
> > it comes with less of a performance price tag than stack guard, should be
> > damn near as effected as stack guard, be one hell of a lot MORE effective
> > than the NES and LWN patches, doesn't require kernel mods like the
> > mobile stack starting point, and doesn't require recompiling all the
> > applications.
> >
> > Anyone got comments on the Bell Labs approach?
>
> Bell's libsafe is good. It will secure a lot of buggy apps quite
> reliably. But it relies upon being able to determine the frame limits
> of strcpy()'s caller. So -fomit-frame-pointer will, it appears, stop it
> working. Vendors (Mandrake at least) are currently shipping
> frame-pointerless shared libs.
>
> Maybe libsafe will cause a rethink of this practice? I sure hope so.
>
> StackGuard is not, in my opinion, as reliable as libsafe (although it's
> good enough). But StackGuard will work with -fomit-frame-pointer.
>
This is exactly the library that i was talking about,
now that the press release is done, i can talk about it :-)
http://www.bell-labs.com/org/11356/libsafe.html
--
-- Yoann, http://prelude.sourceforge.net
It is well known that M$ products don't call free() after a malloc().
The Unix community wish them good luck for their future developments.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:18 EST