Collection of fixes for _FORTIFY_SOURCE

[kevans]

Summary

I'll likely split this up into multiple commits, but each one is small
enough that I think it's best in a single review.

openssl: use getrandom(2) instead of probing for getentropy(2)

The probing for getentropy(2) relies on re-declaring getentropy(2)
as weak and checking the address, but this is incompatible with
the _FORTIFY_SOURCE symbol renaming scheme.  It's always present on
all supported FreeBSD versions now so we could cut it down to
unconditional use, but there's another segment for getrandom(2)
already that's cleaner to just add us to.

We should upstream this.

• include: ssp: fix the build with earlier C standards
  
  inline isn't always a keyword, so we should be using __ssp_inline as we do everywhere else in the _FORTIFY_SOURCE support. Variable declarations in a loop initializer are also not always supported, so declare any loop vars in advance.

• include: ssp: don't shadow the mempcpy builtin
  
  GCC emits a warning about shadowing a builtin with our mempcpy declaration, so switch it to using the same model as memcpy() and use the apparently-existing builtin_mempcpy_chk().

• libc: undefine _FORTIFY_SOURCE for fortified interpose stubs
  
  GCC doesn't like #pragma weak macro(foo)- there's nothing of value to fortify in these files anyways, so just turn it off individually to fix the build.

• sys/select.h: const'ify the fd_set that __fdset_idx() takes
  
  Some callers may be operating on a const fd_set and we don't particularly care, so const'ify it.

• bsnmpd: FreeBSD has strlcpy(3)
  
  Fixes the fortified build with GCC

[imp]

Can you use the __weak_symbol instead of the #pragma weak? I think it's supposed to do the same thing.

[kevans]

In D45976#1048095, @imp wrote:

Can you use the __weak_symbol instead of the #pragma weak? I think it's supposed to do the same thing.

nm(1) seems to think it's fine and it builds fine under GCC as well, so I'll switch to that. Thanks!

[kevans]

Switch to __weak_symbol

[kib]

lib/libc/secure/Makefile.inc

7

Please order alphabetically.

lib/libc/secure/Symbol.map

10

Please order alphabetically

lib/libc/secure/mempcpy_chk.c

32

Do we need cdefs.h? Is it kept to reduce the diff? The file is not in contrib, I think it is better to drop extra include.

[markj]

crypto/openssl/providers/implementations/rands/seeding/rand_unix.c

396

Won't this condition take precedence?

[kevans]

crypto/openssl/providers/implementations/rands/seeding/rand_unix.c

396

Hmm, yeah,; the same is true for NetBSD, so it'll also fallback to the sysctl rather than getrandom(2). NetBSD hasn't removed KERN_ARND either, so maybe just flipping these around wholesale would be fine- I'd hazard a guess that the sysctl often takes more than one trip to fill the buffer on both platforms.

[kevans]

Address review feedback

• Proper sorting
• Needless sys/cdefs.h include removed
• Ordering of sysctl/getrandom use swapped, FreeBSD removed from the sysctl clause since we'll always have getrandom -- ordering mostly for NetBSD's benefit, then, since it seems hard to imagine they'd prefer the 256-byte at a time interface over the arbitrary buffer size interface.

[markj]

crypto/openssl/providers/implementations/rands/seeding/rand_unix.c

400

When upstreaming, I suspect you might want to dig a bit and find a __FreeBSD_version number to check, even though all supported FreeBSD releases have getrandom(). Our implementation hasn't been around all that long in the grand scheme of things, and I think OpenSSL tries harder than most projects to be portable. That said, I'm not sure exactly what their requirements are, so maybe you can just ignore me.

[kevans]

crypto/openssl/providers/implementations/rands/seeding/rand_unix.c

400

*nod* OK, I'll lay out the situation and see how far they care to go

[kevans]

crypto/openssl/providers/implementations/rands/seeding/rand_unix.c

400

Upstreaming here: https://github.com/openssl/openssl/pull/24903 -- I dug out the FreeBSD version for it and left the kern.arandom fallback in place for the earlier versions.