USING FORTIFY

. Before we get into some of the details of our new FORTIFY, let's go through a brief overview of what FORTIFY does, and how it's used. What is FORTIFY? FORTIFY is a set of extensions to the C standard library that tries to catch the incorrect use of standard functions, such as memset, sprintf, open, and others. It has three primary features: If FORTIFY detects a bad call to a standard library function at compile-time, it won't allow your code to compile until the bug is fixed. If FORTIFY doesn't have enough information, or if the code is definitely safe, FORTIFY compiles away into nothing. This means that FORTIFY has 0 runtime overhead when used in a context where it can't find a bug. Otherwise, FORTIFY adds checks to dynamically determine if the questionable code is buggy. If it detects bugs, FORTIFY will print out some debugging information and abort the program. Consider the following example, which is a bug that FORTIFY caught in real-world code: struct Foo { int val; struct Foo *next; }; void initFoo(struct Foo *f) { memset(&f, 0, sizeof(struct Foo)); } FORTIFY caught that we erroneously passed &f as the first argument to memset, instead of f. Ordinarily, this kind of bug can be difficult to track down: it manifests as potentially writing 8 bytes extra of 0s into a random part of your stack, and not actually doing anything to *f. So, depending on your compiler optimization settings, how initFoo is used, and your project's testing standards, this could slip by unnoticed for quite a while. With FORTIFY, you get a compile-time error that looks like: /path/to/file.c: call to unavailable function 'memset': memset called with size bigger than buffer memset(&f, 0, sizeof(struct Foo)); ^~~~~~ For an example of how run-time checks work, consider the following function: // 2147483648 == pow(2, 31). Use sizeof so we get the nul terminator, // as well. #define MAX_INT_STR_SIZE sizeof("2147483648") struct IntAsStr { char asStr[MAX_INT_STR_SIZE]; int num; }; void initAsStr(struct IntAsStr *ias) { sprintf(ias->asStr, "%d", ias->num); } This code works fine for all positive numbers. However, when you pass in an IntAsStr with num asStr. Without FORTIFY, this off-by-one error (that ends up clearing one of the bytes in num) may go silently unnoticed. With it, the program prints out a stack trace, a memory map, and will abort with a core dump. FORTIFY also performs a handful of other checks, such as ensuring calls to open have the proper arguments, but it's primarily used for catching memory-related errors like the ones mentioned above. However, FORTIFY can't catch every memory-related bug that exists. For example, consider the following code: __attribute__((noinline)) // Tell the compiler to never inline this function. inline void intToStr(int i, char *asStr) { sprintf(asStr, “%d”, num); } char *intToDupedStr(int i) { const int MAX_INT_STR_SIZE = sizeof(“2147483648”); char buf[MAX_INT_STR_SIZE]; intToStr(i, buf); return strdup(buf); } Because FORTIFY determines the size of a buffer based on the buffer's type and—if visible—its allocation site, it can't catch this bug. In this case, FORTIFY gives up because: the pointer is not a type with a pointee size we can determine with confidence because char * can point to a variable amount of bytes FORTIFY can't see where the pointer was allocated, because asStr could point to anything. If you're wondering why we have a noinline attribute there, it's because FORTIFY may be able to catch this bug if intToStr gets inlined into intToDupedStr. This is because it would let the compiler see that asStr points to the same memory as buf, which is a region of sizeof(buf) bytes of memory.  FORTIFY works by intercepting all direct calls to standard library functions at compile-time, and redirecting those calls to special FORTIFY'ed versions of said library functions. Each library function is composed of parts that emit run-time diagnostics.***prbxselfnetwork***