Import _FORTIFY_SOURCE implementation from NetBSD

[kevans]

Summary

This is a mostly-unmodified copy of the various *_chk implementations
and headers from NetBSD, without yet modifying system headers to start
actually including them. A future commit will also apply the needed
bits to fix ssp/unistd.h.

[imp]

include/ssp/string.h

100

This is always true...

include/ssp/unistd.h

40

why redirect read(2) and none of the other system calls that write back into user space?

I don't see any others in NetBSD's either. Expanding it is a big ask, so before I really do that as more than maybe a suggestion, I'd like to know the thinking here.

[kevans]

include/ssp/string.h

100

Fair point; I'll hack it back out in the second patch that reworks part of these headers for FreeBSD (with a brief explanation that it's tautological here)

include/ssp/unistd.h

40

I think they more or less tried to stick with the common _FORTIFY_SOURCE implementation (glibc). We can expand it, but IMO let's get to the baseline and define expanding it as future work (explicitly in the commit message) -- the baseline should be 'relatively safe' as folks have been running with glibc's implementation for years as it is.

[kib]

Since this code goes directly into our libc source, and not into vendor import area, should it follow style(9)? The most systematic thing I noted is return a; instead of return (a); Another thing is the headers inclusion order.

include/ssp/ssp.h

38

I do not think lint is relevant for FreeBSD.

lib/libc/secure/sprintf_chk.c

47

These lint-style comments (as well LINTLIBRARY) are not relevant either.

[imp]

include/ssp/unistd.h

40

The counter you your argument may also be that fortify_source was done years ago and is showing its age :)....
But what you suggest works for me, so long as we understand that followup work might be good to increase the coverage. Mostly I wanted to understand why it was incomplete.

[kevans]

Straighten out some style and other bits:

• clang || GCC >= 4.8 is a given
• Remove irrelevant LINT/lint bits
• Shuffle around includes in *_chk.c, alphabetical order with ssp/* headers last
• Remove spurious prototypes in *_chk.c; these should be provided in ssp/*
• return x => return (x)

[emaste]

lib/libssp/Versions.def

3

Is this true?

[kevans]

lib/libssp/Versions.def

3

I added the comment based on the greatest of technicalities, that it appeared in our version of libssp in 13.0-CURRENT (since I added our version of libssp in cd0d51baaa4509a1d); happy enough to revise it, though.

[emaste]

lib/libssp/Versions.def

3

Ok it's fine with me 👍

[gbe]

lib/libssp/ssp.3

121

Would be good if you could also mention FreeBSD here.

[pauamma_gundo.com]

lib/libssp/__builtin_object_size.3

100–101

Matters word order. :-)

lib/libssp/ssp.3

120

"in" missing unless .Nx does more than what I remember .Fx doing. (Maybe let upstream know as well?)

[kevans]

• Fix word order
• "in" before .Nx
• Mention FreeBSD (had GNU version, this version came in in 12.2, enhancements to be in... 14.0)

[pauamma_gundo.com]

Manual pages LGTM. Can't attest to the source or the consistency between them.

[pauamma_gundo.com]

Why didn't I approve it last No... oh right; didn't know I could or should.

[imp]

I think this is fine, modulo notes about its completeness, but I'm OK with that and it's not bad.

[kevans]

In D32306#833118, @imp wrote:

I think this is fine, modulo notes about its completeness, but I'm OK with that and it's not bad.

I'm updating the other reviews to address pending comments; I'd like to land this initial batch that matches what NetBSD has, then I'll start going through other existing headers and see what else we can add.

[imp]

In D32306#1020932, @kevans wrote:

In D32306#833118, @imp wrote:

I think this is fine, modulo notes about its completeness, but I'm OK with that and it's not bad.

I'm updating the other reviews to address pending comments; I'd like to land this initial batch that matches what NetBSD has, then I'll start going through other existing headers and see what else we can add.

I'm good with that.