src-test2/lib/libssp, branch master

libssp: don't compile with -fstack-protector*

2020-03-14T15:15:27Z

This similarly matches what we do in libc; compiling libssp with -fstack-protector* is actively harmful. For instance, if the canary ctor ends up with a stack protector then it will trivially trigger a false positive as the canary's being initialized. This was noted by the reporter as irc/ircd-hybrid started crashing at start after our libssp was MFC'd to stable/11, as its build will explicitly link in libssp. On FreeBSD, this isn't necessary as SSP bits are included in libc, but it should absolutely not trigger runtime breakage -- it does mean that the canary will get initialized twice, but as this is happening early on in application startup it should just be redundant work. Reported by: Tod McQuillin MFC after: 3 days

libssp: fix FORTIFY_SOURCE stub declarations

2020-01-04T22:05:00Z

The LSB 4.1 that I referenced omitted the varargs, and I failed to catch it. The __vsnprintf_chk error was from just downright misreading the page. GCC6 caught all of these, but I had only tested GCC4.2. X-MFC-With: r356356

Provide libssp based on libc

2020-01-04T20:19:25Z

For libssp.so, rebuild stack_protector.c with FORTIFY_SOURCE stubs that just abort built into it. For libssp_nonshared.a, steal stack_protector_compat.c from ^/lib/libc/secure and massage it to maintain that __stack_chk_fail_local is a hidden symbol. libssp is now built unconditionally regardless of {WITH,WITHOUT}_SSP in the build environment, and the gcclibs version has been disconnected from the build in favor of this one. PR: 242950 (exp-run) Reviewed by: kib, emaste, pfg, Oliver Pinter (earlier version) Also discussed with: kan MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D22943