1. 10

  2. 1

    I wasn’t aware of _FORTIFY_SOURCE, and now I’ve promptly added it to my CMakeLists for Linux GCC builds. Then I tried to figure out if Clang/libc++ supports it too.

    Long story short, apparently it does, based on the C/C++ headers in Xcode 14. And <_types.h> includes this:

    #ifndef _FORTIFY_SOURCE
    #    define _FORTIFY_SOURCE 0
    #  else
    #    define _FORTIFY_SOURCE 2	/* on by default */
    #  endif

    …meaning that level 2 has been on by default since, hm, macOS 10.5. Good to know.

    1. 2

      A few years ago, I was at a presentation by the Android security team where they were proud of how they’d added support for it to Android. I’d worked with the GSoC student who added it to FreeBSD and couldn’t work out what it would catch (dynamically, at run time) that the clang static analyser wouldn’t catch at compile time, so I asked the Google folks what they’d seen. Their reply was that static analysis was not part of their developer workflow.

      I consider fortify source to be process smell: if it’s anything other than security theatre for your project then it implies that you’re not using tooling that could catch the bugs at compile time.

      1. 2

        The more places you can catch bugs the better. If it happens to find a flipped bit that no compile time check could have predicted, it has helped, right?

        1. 1

          Imagine two tools:

          The first runs at compile time and tells you where a bug is so that you can fix it.

          The second adds run-time instrumentation that slows down your code, catches a subset of the same bugs, and just tells you something went wrong (or, rather, tells the user, and relies on you having telemetry to catch stack traces and so on).

          Given the existence of the first, why would you want to enable the second?