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>