Re: Further work on FORTIFY_SOURCE

On 6/21/24 21:22, Kyle Evans wrote:
> Hi,
> 
> Sponsored by Stormshield and Klara, I've completed an extension of the 
> original FORTIFY_SOURCE work that landed a couple weeks ago.  This set 
> includes both a test framework to make sure that it's more or less 
> working as we expect, along with fortification of many, many more libc 
> functions & syscalls.  The relevant reviews are in a stack starting at 
> https://reviews.freebsd.org/D45676 and include:
> 
> D45676 Prepare some build fixes in advance of more _FORTIFY_SOURCE
> D45677 libc: move __ssp_overlap back out into <ssp/ssp.h>
> D45678 libc: tests: add testing infrastructure for _FORTIFY_SOURCE
> D45679 include: ssp: round out fortification of current set of headers
> D45680 include: ssp: fortify poll/ppoll from <poll.h>
> D45681 include: ssp: fortify <stdlib.h>
> D45682 include: ssp: fortify <wchar.h>
> D45683 include: ssp: fortify <sys/random.h>
> D45684 include: ssp: fortify <sys/uio.h>
> D45685 include: ssp: fortify <sys/select.h>
> D45686 include: ssp: fortify <sys/socket.h>
> 
> I've pushed a branch to Klara's GitHub as well for anyone interested in 
> trying to consume it in that format:
> 
> https://github.com/KlaraSystems/freebsd/commits/stormshield/fortify_source/
> 
> Review and feedback are welcome- I've been running the full set on my 
> laptop and my build machine with no obvious issues
> 
> One caveat that we'll need to work through is that the lang/gcc* ports 
> include some <ssp/*> headers, so those ports can't be used to build 
> anything with _FORTIFY_SOURCE enabled (not compatible with ours).  These 
> headers should almost certainly just go away at this point -- the 
> improvement in the feature with GCC comes from the builtin 
> implementations, not from whatever they've written in these headers.
> 

FYI- these all have clean reviews now and I believe all feedback has 
been addressed.  I'm doing some last minute smoke tests with my laptop 
and build machine to exercise a number of common paths where we could 
have something funky, but without sufficient objection I'll be pushing 
this series around ~24h from now, give or take a little bit, assuming 
the tests go alright.

Thanks,

Kyle Evans