Date: Tue, 14 May 2024 16:00:26 +0000 From: Shawn Webb <shawn.webb@hardenedbsd.org> To: Alexander Leidinger <Alexander@leidinger.net> Cc: Kyle Evans <kevans@freebsd.org>, Tomoaki AOKI <junchoon@dec.sakura.ne.jp>, Cy Schubert <Cy.Schubert@cschubert.com>, "freebsd-hackers@FreeBSD.org" <freebsd-hackers@freebsd.org> Subject: Re: Initial implementation of _FORTIFY_SOURCE Message-ID: <lhreekti7g2l3vwcr2rp327l6kcf67xx7qaexnj2wtknryeywu@w6vlmptjuj3w> In-Reply-To: <5544c172efe031ecdbabd2a93980cdd5@Leidinger.net> References: <f8000e6b-226b-45f3-a751-aca790f4f8c8@FreeBSD.org> <20240513180924.29C872B4@slippy.cwsent.com> <hxql75nrkuggdcjtocsbcezvjfxa4bblg3iyqy46rqnju66ozx@6nmq3uczc7y4> <20240514080517.36f218aa3a054aa2cba99b0d@dec.sakura.ne.jp> <9d4a06bc-44fd-4e9a-8615-cd71127fc90e@FreeBSD.org> <5544c172efe031ecdbabd2a93980cdd5@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--bk7rzmbuwmjw54qv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 14, 2024 at 09:21:09AM +0200, Alexander Leidinger wrote: > Am 2024-05-14 05:16, schrieb Kyle Evans: > > On 5/13/24 18:05, Tomoaki AOKI wrote: > > > On Mon, 13 May 2024 18:57:26 +0000 > > > Shawn Webb <shawn.webb@hardenedbsd.org> wrote: > > >=20 > > > > On Mon, May 13, 2024 at 11:09:24AM -0700, Cy Schubert wrote: > > > > > In message > > > > > <f8000e6b-226b-45f3-a751-aca790f4f8c8@FreeBSD.org>, Kyle > > > > > Evans > > > > > write > > > > > s: > > > > > > Hi, > > > > > >=20 > > > > > > As of 9bfd3b407 ("Add a build knob for > > > > > > _FORTIFY_SOURCE"), I've imported > > > > > > an initial version of FORTIFY_SOURCE from FreeBSD. > > > > > > FORTIFY_SOURCE is an > > > > > > improvement over classical SSP, doing compiler-aided > > > > > > checking of stack > > > > > > object sizes to detect more fine-grained stack overflow > > > > > > without relying > > > > > > on the randomized stack canary just past the stack frame. > > > > > >=20 > > > > > > This implementation is not yet complete, but we've done a revie= w of > > > > > > useful functions and syscalls to add checked variants of > > > > > > and intend to > > > > > > complete the implementation over the next month or so. > > > > > >=20 > > > > > > Please test _FORTIFY_SOURCE out now by setting > > > > > > FORTIFY_SOURCE=3D2 in the > > > > > > buildworld env -- I intend to flip the default to 2 when > > > > > > WITH_SSP is set > > > > > > in the next month if nobody complains about serious breakage. = I've > > > > > > personally been rolling with FORTIFY_SOURCE=3D2 for the > > > > > > last three years > > > > > > that this has been sitting in a local branch, so I don't really > > > > > > anticipate any super-fundamental breakage. > > > > >=20 > > > > > Should this trigger a __FreeBSD_version bump? > > > >=20 > > > > I would encourage that so to help the ports tree determine > > > > availability of the import. > > >=20 > > > If it can be enabled/disabled with sysctls/tunables on > > > runtime/boottime, > > > bump should be preferred. Maybe this isn't yet the case here, IIUC. > > >=20 > > > But if it could be done only on build time with WITH_ or WITHOUT_ knob > > > ad not yet enabled by default for now, now ins't the time to bump. > > > Bump should be done when it becomes to be built by default. > > >=20 > > > Bump for non-default build time knob should force poudriere[-devel] > > > users massive unneeded rebuilds. So should be avoided, if it still > > > cannot switch on boot or runtime. > > >=20 > >=20 > > It's strictly build time, and I didn't really see the value in bumping > > __FreeBSD_version for it. I don't see any reason to, e.g., turn it into > > a per-port option that we may not want to have if the feature isn't > > there, and the knob to build it in is a preprocessor define that's > > harmless if the feature isn't actually available. >=20 > Ports: We have WITH_PIE, WITH_BIND_NOW and WITH_RELRO (e.g. for make.conf) > which enables those build time options globally. Ports then can have e.g. > PIE_UNSAFE=3Dyes to opt-out of WITH_PIE builds. I think it would be benef= icial > if we get something similar for FORTIFY. I already use all of the afore > mentioned options in my own builds (and have provided NO_PIE hints where = it > fails), and I would surely give a similar FORTIFY option a try. >=20 > On a somewhat related note, has someone already played with CFI > (https://clang.llvm.org/docs/ControlFlowIntegrity.html)? HardenedBSD applies non-Cross-DSO CFI to (nearly) all applications in base and has some integration in ports, with a few ports opting into CFI. Feel free to reach out directly to me for specific questions so that we don't get off-topic for this mailing list thread. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --bk7rzmbuwmjw54qv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmZDio8ACgkQ/y5nonf4 4fqTSBAAgw3oQ5FXevxnUxaDza5dIGTr5iNYrPxIKEaFRAykyHCNSkrI0LX6O0bL 3IkrRYTKHosfzsUPanY8aOAv4Fmh1BNW6x2/je2aIjQf8j8O82sV/7RFSWjANN56 sm0aTWn/8i9b77f3ua4GgZ33aK8ZZ57yU98tQiHFEYfbx/fwkniC2xxmMPaVLex2 Pt//VARBd5EeiMgJgkdlsk/qByN3eCA8YVAw+k71FJ5z/9NidDcEzspgxS4B5yRr P/bx3KMrCtUTZkgAHyfLL1SSH+KFXA4Ci0fDNOE82hp4VtAtQMBMVp8JniPZTvz3 w3bEH2XejytOJQEBX9jT5slF2ZCCSQz7aB3K+3FrgBR22RtKYFZRhxPIkTv0AHVm xahxJd0n50s4oObbTyRgKPoecwdNjAkVMCRDLi5Au25rX3ZxACDWe/Dc/vWkyKva MpB/nthqxYn69wn9d/WOjlEQFQaYdv8rMvKAY8niTW6G/hxLA36IwKoJx+KDtTqW SxFcuZr4wTDCniCbefi09Qig/5JjI3yorhDis7hcjtlYC+dcM5TxvS8fe1Qh6HwP LIvHiFhvIjrD3Nwhqmd49jUxHKVNCQ9CFwR9WB7bjaZd71c+bTVsEOfRqXFHIt8I Va1Y7Qt5cYr9ThGKM+qbDaa0rCtGe2icn3sHvtZV8SLRS+FVkkw= =+GJW -----END PGP SIGNATURE----- --bk7rzmbuwmjw54qv--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?lhreekti7g2l3vwcr2rp327l6kcf67xx7qaexnj2wtknryeywu>