Re: Initial implementation of _FORTIFY_SOURCE

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:
> > > 
> > > > 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,
> > > > > > 
> > > > > > 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.
> > > > > > 
> > > > > > This implementation is not yet complete, but we've done a review of
> > > > > > useful functions and syscalls to add checked variants of
> > > > > > and intend to
> > > > > > complete the implementation over the next month or so.
> > > > > > 
> > > > > > Please test _FORTIFY_SOURCE out now by setting
> > > > > > FORTIFY_SOURCE=2 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=2 for the
> > > > > > last three years
> > > > > > that this has been sitting in a local branch, so I don't really
> > > > > > anticipate any super-fundamental breakage.
> > > > > 
> > > > > Should this trigger a __FreeBSD_version bump?
> > > > 
> > > > I would encourage that so to help the ports tree determine
> > > > availability of the import.
> > > 
> > > 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.
> > > 
> > > 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.
> > > 
> > > 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.
> > > 
> > 
> > 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.
> 
> 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=yes to opt-out of WITH_PIE builds. I think it would be beneficial
> 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.
> 
> 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,

-- 
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/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc