libssp is part of GCC, not an independent library.

[pfg]

Summary

libssp is one of the GNU removal show stoppers: it is used for stack
protection but it is fundamentally a compiler library.

Checking r333398 and r333399 have dropped the requirement to build rtld
with an SSP-enabled libc. Setting libssp along with the other gcclibs
should make things clearer now.
I am not an expert on the build. Hopefully this is enough to stop libssp
from building when we are not using the GNU toolchain?

Test Plan

This is passing a tinderbox build. I am unsure if it is correct or if we
have to add something else; for example in ObsoleteFiles.inc.
Just thought I'd pass the idea around to someone that knows better.

[pfg]

For the record: the compiler libssp is not the same as libssp as in NetBSD and bionic's libc, which implements the libc support for FORTIFY_SOURCE.

[brooks]

In terms of exposed symbols (see objdump -T), libssp definitely is a FORTIFY_SOURCE implementation. I've not looked at the code to avoid contamination in case we need a cleanroom one.

[pfg]

In D15687#339162, @brooks wrote:

In terms of exposed symbols (see objdump -T), libssp definitely is a FORTIFY_SOURCE implementation. I've not looked at the code to avoid contamination in case we need a cleanroom one.

Well,libssp is not functional as-is on FreeBSD: we are missing wrappers that translate regular C functions into the libssp calls when defining FORTIFY_SOURCE. I think we can safely remove it.

NetBSD has a clean implementation but the feature is pretty much GCC dependent. We also have a GSoC2015 implementation based on early Bionic sources but IMHO we shouldn't implement it at all.

[brooks]

That makes sense. If in fact nothing ever linked to it then we should just relegate it to the compat11 port and kill it along with gcc.

[emaste]

For reference, BSDL __stack_chk_fail in Android https://android.googlesource.com/platform/bionic/+/ics-mr1-release/libc/bionic/ssp.c and NetBSD http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/misc/stack_protector.c?annotate=1.9&only_with_tag=MAIN.

The libssp subdir should be added only if both MK_SSP and MK_GCC are true; someone who sets WITHOUT_SSP but WITH_GCC should not get it. Also, it seems there are other MK_SSP conditionals that need to be investigated in other Makefiles and share/mk.

[brooks]

In D15687#339170, @emaste wrote:

For reference, BSDL __stack_chk_fail in Android https://android.googlesource.com/platform/bionic/+/ics-mr1-release/libc/bionic/ssp.c and NetBSD http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/misc/stack_protector.c?annotate=1.9&only_with_tag=MAIN.

We have our own in lib/libc/secure/stack_protector.c

[pfg]

In D15687#339170, @emaste wrote:

For reference, BSDL __stack_chk_fail in Android https://android.googlesource.com/platform/bionic/+/ics-mr1-release/libc/bionic/ssp.c and NetBSD http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/misc/stack_protector.c?annotate=1.9&only_with_tag=MAIN.

The libssp subdir should be added only if both MK_SSP and MK_GCC are true; someone who sets WITHOUT_SSP but WITH_GCC should not get it. Also, it seems there are other MK_SSP conditionals that need to be investigated in other Makefiles and share/mk.

In NetBSD SSP stands for two different things: the stack protector and FORTIFY_SOURCE. Our stack protector is based on the NetBSD but we never really brought the FORTIFY_SOURCE stuff, in particular the headers trickery.

The GSoC 2015 did an implementation of FORTIFY_SOURCE based on NetBSD implementation but extended it with the old Bionic stuff. theraven@ pointed out many issues and It never worked very well on clang, plus newer technologies have rendered it obsolete.

AFAICT NetBSD doesn't use the GCC libssp in their libc. If GCC's libssp is effectively only FORTIFY_SOURCE, it could be removed, but I also admit I haven't looked at it at all.

What I will do next is a ports exp-run to make sure we are not linking the libssp stuff in ports.

[emaste]

In D15687#339170, @emaste wrote:

The libssp subdir should be added only if both MK_SSP and MK_GCC are true; someone who sets WITHOUT_SSP but WITH_GCC should not get it.

Hrm, I think I'm wrong here: MK_SSP is documented (in src.conf) as controlling whether the world should be built with ssp or not, so I think the change is fine (pending the outcome of your exp-run and other experiments).

[antoine]

All ports fail to build with this patch

[pfg]

In D15687#340674, @antoine wrote:

All ports fail to build with this patch

Thanks, Quoting PR 229348:

From config.log:

configure:3586: checking whether the C compiler works
configure:3608: cc -O2 -pipe -Wno-error -fstack-protector -fno-strict-aliasing

-fstack-protector conftest.c  >&5

/usr/bin/ld: error: cannot open /usr/lib/libssp_nonshared.a: No such file or
directory
cc: error: linker command failed with exit code 1 (use -v to see invocation)

Part of the idea to test this change originally was indeed to see where we need libssp.
I am running the patch on FreeBSD 11-stable and ports still build. Maybe this has something to do with r333398.
CCing kib@ JIC he may share some light.

[kib]

I fail to understand this. What is built instead of libssp when MK_GCC is NO ? If the answer is nothing, then you get non-functional system.

So what is the point of this patch ?

[pfg]

In D15687#340718, @kib wrote:

I fail to understand this. What is built instead of libssp when MK_GCC is NO ? If the answer is nothing, then you get non-functional system.

The answer is indeed nothing. Why is the system non-functional? Why do we need libssp and is there documentation to replace it?

So what is the point of this patch ?

The point is that libssp is part of GCC so we need to know what we need to replace it with (without looking insidie since its GPLd).
If libssp is for FORTIFY_SOURCE then we got something wrong because FORTIFY_SOURCE is not functional on FreeBSD.

[kib]

In D15687#340719, @pfg wrote:

In D15687#340718, @kib wrote:

I fail to understand this. What is built instead of libssp when MK_GCC is NO ? If the answer is nothing, then you get non-functional system.

The answer is indeed nothing. Why is the system non-functional? Why do we need libssp and is there documentation to replace it?

Because you need to satisfy the ssp symbols to get working binaries.

So what is the point of this patch ?

The point is that libssp is part of GCC so we need to know what we need to replace it with (without looking insidie since its GPLd).

I am even more confused now. Why did not you answered this question for yourself before even proposing to remove libssp by the switch ?

Goal is to have the functional system, and to have it GPL-free is somewhere in the second line.

If libssp is for FORTIFY_SOURCE then we got something wrong because FORTIFY_SOURCE is not functional on FreeBSD.

[pfg]

In D15687#340720, @kib wrote:

In D15687#340719, @pfg wrote:

In D15687#340718, @kib wrote:

I fail to understand this. What is built instead of libssp when MK_GCC is NO ? If the answer is nothing, then you get non-functional system.

The answer is indeed nothing. Why is the system non-functional? Why do we need libssp and is there documentation to replace it?

Because you need to satisfy the ssp symbols to get working binaries.

So what is the point of this patch ?

The point is that libssp is part of GCC so we need to know what we need to replace it with (without looking insidie since its GPLd).

I am even more confused now. Why did not you answered this question for yourself before even proposing to remove libssp by the switch ?

Well, that was the question I was asking myself. I moved libssp along with the other libgcc libs (where it came from) and buildworld still works, I get no missing symbols anywhere.
I theorized that we appear to have added the FORTIFY_SOURCE functions but we are not using them anywhere.

Ports are working still on my machine (11-stable), after building without libssp:

file /usr/lib/libssp_nonshared.a:
/usr/lib/libssp_nonshared.a:: cannot open `/usr/lib/libssp_nonshared.a:' (No such file or directory)

Goal is to have the functional system, and to have it GPL-free is somewhere in the second line.

Yes, I am just trying to identify why current is non-functional without the GPL'd piece.

The patch was not really a proposal, I was hoping to understand better the problem so someone more involved with it could find it easier to solve.
If the effort is not welcome I can always abandon the revision and waste time on something more useful.

[kib]

In D15687#340721, @pfg wrote:

In D15687#340720, @kib wrote:

In D15687#340719, @pfg wrote:

In D15687#340718, @kib wrote:

I fail to understand this. What is built instead of libssp when MK_GCC is NO ? If the answer is nothing, then you get non-functional system.

The answer is indeed nothing. Why is the system non-functional? Why do we need libssp and is there documentation to replace it?

Because you need to satisfy the ssp symbols to get working binaries.

So what is the point of this patch ?

The point is that libssp is part of GCC so we need to know what we need to replace it with (without looking insidie since its GPLd).

I am even more confused now. Why did not you answered this question for yourself before even proposing to remove libssp by the switch ?

Well, that was the question I was asking myself. I moved libssp along with the other libgcc libs (where it came from) and buildworld still works, I get no missing symbols anywhere.
I theorized that we appear to have added the FORTIFY_SOURCE functions but we are not using them anywhere.

Ports are working still on my machine (11-stable), after building without libssp:

file /usr/lib/libssp_nonshared.a:
/usr/lib/libssp_nonshared.a:: cannot open `/usr/lib/libssp_nonshared.a:' (No such file or directory)

Goal is to have the functional system, and to have it GPL-free is somewhere in the second line.

Yes, I am just trying to identify why current is non-functional without the GPL'd piece.

If you do not provide libssp(_nonshared.a), then you should disable -f option for ssp, which is probably enabled by default in the spec for gcc, and somewhere in c++ for clang.

The patch was not really a proposal, I was hoping to understand better the problem so someone more involved with it could find it easier to solve.
If the effort is not welcome I can always abandon the revision and waste time on something more useful.

[pfg]

In D15687#340722, @kib wrote:

In D15687#340721, @pfg wrote:

In D15687#340720, @kib wrote:

In D15687#340719, @pfg wrote:

In D15687#340718, @kib wrote:

I fail to understand this. What is built instead of libssp when MK_GCC is NO ? If the answer is nothing, then you get non-functional system.

The answer is indeed nothing. Why is the system non-functional? Why do we need libssp and is there documentation to replace it?

Because you need to satisfy the ssp symbols to get working binaries.

So what is the point of this patch ?

The point is that libssp is part of GCC so we need to know what we need to replace it with (without looking insidie since its GPLd).

I am even more confused now. Why did not you answered this question for yourself before even proposing to remove libssp by the switch ?

Well, that was the question I was asking myself. I moved libssp along with the other libgcc libs (where it came from) and buildworld still works, I get no missing symbols anywhere.
I theorized that we appear to have added the FORTIFY_SOURCE functions but we are not using them anywhere.

Ports are working still on my machine (11-stable), after building without libssp:

file /usr/lib/libssp_nonshared.a:
/usr/lib/libssp_nonshared.a:: cannot open `/usr/lib/libssp_nonshared.a:' (No such file or directory)

Goal is to have the functional system, and to have it GPL-free is somewhere in the second line.

Yes, I am just trying to identify why current is non-functional without the GPL'd piece.

If you do not provide libssp(_nonshared.a), then you should disable -f option for ssp, which is probably enabled by default in the spec for gcc, and somewhere in c++ for clang.

Thanks, that is a good hint.

Hmm... that just makes things ugly/complex though: libssp is part of gcclibs so GCC should carry its own and somehow just work. We shouldn't have to touch the specs on GCC (in particularly not in ports).
I don't know about clang but somehow my 11-stable box works fine without libssp.

This just got out of my league. Hope someone else find the experiment useful.

Thanks again.

[pfg]

Abandon: it does seem like we can just remove libssp but I don't have time to dig deeper.

[pfg]

I think the problem in libssp_nonshared.a is brought in bogusly by the
libc.ldscript.

I did a small update and added some changes for share.mk as we should
not need libssp at all when building with clang.

There is still a mysterious failure on powerpc (libcom_err).

[antoine]

Did you verify that the problem on i386 described in r251668 no longer occurs?

[pfg]

In D15687#459500, @antoine wrote:

Did you verify that the problem on i386 described in r251668 no longer occurs?

No, thanks for the link. Two quick notes:

1. we don't use GCC on i386 anymore.
2. There shouldn't be any calls to libssp, that is the only point of this change. Quoting the revision:

It is important to understand that the object file contained in this library will be pulled in the resulting binary _only if_ the linker notices one of its symbols is needed (i.e. one of the SSP symbol is missing).

My tinderbox build on i386 completed well:
$ tail _.i386.i386.buildworld

tests/sys/vm (all)

etc (all)

etc/sendmail (all)

usr.bin/clang/lldb (all)

usr.bin/clang/llvm-cov (all)

usr.bin/clang/llvm-profdata (all)

---

World build completed on Sat Aug 3 21:36:54 UTC 2019
World built in 10611 seconds, ncpu: 32, make -j8

---

The only way to be sure is running the code in a VM though.

[pfg]

Overcome by D22943 and SVN r356356.