svn commit: r367577 - in head: share/mk sys/conf tools/build/options

[Brooks Davis]

On Tue, Nov 10, 2020 at 02:44:45PM -0500, Shawn Webb wrote:
> On Tue, Nov 10, 2020 at 07:17:29PM +0000, Brooks Davis wrote:
> > On Tue, Nov 10, 2020 at 07:15:14PM +0000, Brooks Davis wrote:
> > > Author: brooks
> > > Date: Tue Nov 10 19:15:13 2020
> > > New Revision: 367577
> > > URL: https://svnweb.freebsd.org/changeset/base/367577
> > > 
> > > Log:
> > >   Support initializing stack variables on function entry
> > >   
> > >   There are two options:
> > >    - WITH_INIT_ALL_ZERO: Zero all variables on the stack.
> > >    - WITH_INIT_ALL_PATTERN: Initialize variables with well-defined patterns.
> > >   
> > >   The exact pattern are a compiler implementation detail and vary by type.
> > >   They are somewhat documented in the LLVM commit message:
> > >   https://reviews.llvm.org/rL349442
> > >   I've used WITH_INIT_ALL_* to match Microsoft's InitAll feature rather
> > >   than naming them after the LLVM specific compiler flags.
> > >   
> > >   In a range of consumer products, options like these are used in
> > >   both debug and production builds with debugs builds using patterns
> > >   (intended to provoke crashes on use of uninitialized values) and
> > >   production using zeros (deemed more likely to lead to harmless
> > >   misbehavior or NULL-pointer dereferences).
> > 
> > We've tested this extensively in CheriBSD on RISC-V, in the wild it's
> > probably most tested on Arm64 and x86.
> > 
> > Despite the silly compiler flag you'll spot in the code, the zeroing
> > option isn't going away in practice as Apple, Google, and Microsoft all
> > ship with this feature in some of their products.
> 
> HardenedBSD's testing of this last year on amd64 have (privately)
> shown the feature to really hinder performance on more complex
> applications (like when applied to clang/lld). A build of base
> without init all zero applied to clang/lld would take around 1.5
> hours on my system. A build with it applied to clang/lld took around
> four hours, if my memory serves correctly. I would probably advise
> against applying it system-wide. But YMMV.

I agree a more nuanced approach is likely useful in practice, but this
does work and is part of the configuration we shipped for DARPA's FETT bug
bounty.  Hopefully this provides a starting point for further
exploration.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20201110/855da19f/attachment.sig>