Hi, On Wed, 09 Mar 2011 09:35:32 +0100 "Peter Mazinger" <[email protected]> wrote:
> Hello William, > > [...] > > I have plans for working on the FORTIFY stuff after 0.9.32 release, > > which is why I went ahead and set up the libc_hidden_proto/def for > > it. > > > > Would you prefer I resubmit with only the __chk_fail function set up > > for now? > > I have committed some preliminaries to start with fortify support, > for now *_chk() and __chk_fail() functions are disabled That solution works for me in the short term, but getting FORTIFY up and running is definitely a goal of mine. > > Generally, to get this option going, the headers have to reviewed, > many of them are missing the section about FORTIFY. Generic version > of the *_chk() functions should be first implemented, so that support > can be enabled without caring if one arch has some adapted > implementation. The __chk_fail() function could go to a separate > file, to be independent of the ssp option, for this block_signals(), > terminate() and ssp_write() need to be made hidden instead of static > (and provided if either SSP or FORTIFY are enabled). Alternatively > the ssp.c could be renamed to hardened.c I am wondering if we should > also have an option to compile uClibc with -D_FORTIFY_SOURCE=2 hardened.c sounds good to me, and -D_FORTIFY_SOURCE=2 compilation also sounds good. William _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
