Date: Thu, 11 Jul 2024 22:30:57 -0500 From: Kyle Evans <kevans@FreeBSD.org> To: "freebsd-hackers@FreeBSD.org" <freebsd-hackers@freebsd.org> Subject: Re: Further work on FORTIFY_SOURCE Message-ID: <9d2a7044-6d58-418a-9255-658eaf063c36@FreeBSD.org> In-Reply-To: <89e3763a-093f-4ac2-a785-fe95448061f4@FreeBSD.org> References: <89e3763a-093f-4ac2-a785-fe95448061f4@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9d2a7044-6d58-418a-9255-658eaf063c36>