Provide libssp based on libc

[kevans]

Summary

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.

[kevans]

Regenerate with full context... grr...

[kevans]

Remove all the useless version maps; that's not how linker filters work, and the nonshared one was copy-pasto.

[kevans]

Rewrite: libssp now recompiles stack_protector.c and provides the symbols under LIBSSP_1.0 as they're supposed to be compatible.

libssp_nonshared now compiles stack_protector_compat.c instead of the goofiness it was doing before. I've modified it lightly to match what we need in libssp, rather than effectively duplicating the file. I think it's still rather readable...

[kevans]

Address comment by kan- don't bother avoiding the duplication, it's a small object.

The libc/secure changes will get committed independently, as they're a nop that just fix warnings exposed by libssp build (missing declaration, signed vs. unsigned comparison mismatch, directly casting away volatile qualifier)

[kan]

Looks fine to me.

[kevans]

Provide the missing _FORTIFY_SOURCE symbols, as per kib. These have never been linked against or used as far as we can tell because doing so requires major header surgery to make it happen. We cannot proceed in a reasonable fashion if they do happen to get called, so abort.

[kevans]

I've created an exp-run for this, PR 242950. The patch in the exp-run is complete removal of gcclibs' libssp from the build and adds an SSP_SUPPORT knob that controls whether libssp libs/tests are built. At the moment it has dependency on MK_SSP so that the defaults remain consistent across the switch, then a later change can remove the dependency and just mark SSP_SUPPORT as BROKEN on mips, default on everywhere else. SSP_SUPPORT specifically controls:

• libc ssp tests
• libc linking against libssp_nonshared (possibly going away anyways, but included for completeness)
• building libssp/libssp_nonshared

because after discussion with emaste, controlling all of this with SSP seems silly -- the verbiage of the option would imply that we just don't use -fstack-protector* when building base, rather than not building any of the libs.

Also adding pfg, who I've now realized also has an interest in libssp.

[pfg]

I am fine with this approach: while we do have an implementation of these functions (GSoC 2015), I don't think FORTIFY_SOURCE solves anything that we don't already do with the strong stack protector. Stubbing the functions out is a quick and practical solution.
We should still consider removing the stubs in a near future: I haven't looked at how linux does it but I think this stuff is not carried by glibc but in GCC libs instead.

[pfg]

Let me add Oliver as he was my student for GSoC 2015.

Two notes to clarify:

1. the stack protector and FORTIFY_SOURCE are different things, they offer similar protections at different levels, but when implementing them, NetBSD put them together under the SSP blanket: we inherited that mistake.
2. FORTIFY_SOURCE was never really implemented in our headers so any use we have is an error. Furthermore, it never worked with clang like it did with GCC so I am not sure what the tests we brought form NetBSD actually do.

Since the urgency is deleting the GPL'd library, stubbing is fine, but after that we should just cleanup any trace of FORTIFY_SOURCE.
Musl libc has a particular implementation that is done with inline functions, only in headers: it is GCC-only but it doesn't need to touch the C library. For more details, feel free to ask in private, it doesn't make sense to spam the Differential ;).

[op]

LGTM

[kevans]

Update based on the patch from the exp-run, with another bug or two in the build pinched. Most of the diff is mechanical replacement of gnu/lib -> lib and libssp_nonshared moving out of lib/libssp.

Also included is a new knob, SSP_SUPPORT, that specifically controls whether libssp is built or not. SSP is forced off if we don't build with SSP_SUPPORT.

[emaste]

Makefile.inc1

2791

I think the other _SUPPORT knobs have a different meaning - they control whether some optional functionality is used in binaries, e.g. WITHOUT_BZIP2_SUPPORT builds things without linking against libbz2.

I think SSP_SUPPORT actually sounds right (and probably the others all have the wrong sense, and should be something like WITHOUT_BZIP2_USE instead) but it does seem inconsistent. So I don't know what the best answer is, whether this knob should be renamed from SSP_SUPPORT or not.

lib/libssp/Symbol.map

11

Do you know where Linux / glibc puts these? Is our putting them in libssp just a historical accident?

Perhaps we should also add a comment that we believe these have never been used on FreeBSD.

[kevans]

• Knock out the SSP_SUPPORT knob entirely. This is a relatively small part of the build, just do it.
• Add a SUBDIR_DEPEND_libc on libssp_nonshared instead of another .WAIT
• "_elf_aux_info" is called "elf_aux_info" when you're not libc, -D_elf_aux_info=elf_aux_info for the libssp build.
• Add a note about the FORTIFY_SOURCE symbols in the symbol map

[kevans]

lib/libssp/Symbol.map

11

gcc9 still seems to keep them in libssp, so I guess nothing's changed from what we have in base gcclibs.

[emaste]

Let's go for it (pending exp-run) and tidy up / adjust from there.

[kib]

lib/libssp/Makefile

6

Well, if you bump the dso version number, then it makes no sense to keep symbols for binary compatibility. But our promise was that we would never (take it with some skepticism) bump version number for symver-ed dso.

IMO you should keep the existing version and remove libssp.so.0 from obsolete libs. You are providing perfect ABI-compatible replacement.

[kevans]

Drop version back to libssp.so.0 and remove corresponding entries from ObsoleteFiles.inc.

[kevans]

lib/libssp/Makefile

6

Sure- sounds reasonable to me.

[pfg]

Cool.
FWIW, it may make sense to MFC this code: it is under strong copyleft and getting linked with everything.