This page documents the Ubuntu-specific default compiler flags in the toolchain used to help provide additional security features to Ubuntu. It is based on the work from GccSsp, Security/HardeningWrapper, and DistCompilerFlags. Please attempt to fix a source package's problems before disabling a given compiler feature, and document the package and bug numbers in the Problems section below.

Default Flags

-fstack-protector --param=ssp-buffer-size=4

First enabled in Ubuntu 6.10. Enabled run-time stack overflow verification. See GccSsp for further details. Most problems are related to packages that do not use stdlib directly (kernel modules, certain libraries, etc).

Starting in Ubuntu 10.10, --param ssp-buffer-size=4 was added as well to increase the number of functions protected by the stack protector. (The upstream default is "8".)

Failure examples:

Disabled with -fno-stack-protector or -nostdlib in CPPFLAGS.


First enabled in Ubuntu 8.10. Provides compile-time best-practices errors for certain libc functions, and provides run-time checks of buffer lengths and memory regions. Only activated when compiled with -O1 or higher. Most problems are related to common unsafe uses of certain libc functions. (For implementation details, see this post. Starting with Jaunty, fwrite was removed from the list of functions that are marked with "warn_unused_result".)

Failure examples:

Disable unused result tests with -Wno-unused-result in CPPFLAGS. Totally disabled with -U_FORTIFY_SOURCE or -D_FORTIFY_SOURCE=0 in CFLAGS.

-Wformat -Wformat-security

First enabled in Ubuntu 8.10. Enables compile-time warnings about misuse of format strings, some of which can have security implications. These options should only cause build failures if the package is compiling with -Werror or -Werror=format-security. For details on marking up source to gain these warnings, see the glib macro documentation about gcc's "format" attribute.

Failure examples:

Note: -Werror=format-security is turned on by default in 13.04 and later releases of Ubuntu.

Disabled with -Wno-format-security or -Wformat=0 in CPPFLAGS.

Flags passed to the linker


First enabled in Ubuntu 8.10. Provides a read-only relocation table area in the final ELF. This option paves the way for using -z now which forces all relocations to be resolved at run-time (which would cause some additional initial load delay), providing an even higher level of protection to the relocation table -- it could then be entirely read-only which can be used to further harden long-running programs like daemons.

No known failure examples.

Disabled with -Wl,-z,norelro in LDFLAGS.


First enabled in Ubuntu 8.04 (or earlier?) as -Wl,--hash-style=both. Enabled as -Wl,--hash-style=gnu in Ubuntu 10.10. Set the type of the linker's hash table(s). The gnu hash style results in smaller objects and faster dynamic linking at runtime.


Also known as --no-add-needed. First enabled in Ubuntu 11.04 (but disabled in the final 11.04 release), and permanently enabled in Ubuntu 11.10. This option affects the treatment of dynamic libraries referred to by DT_NEEDED tags inside ELF dynamic libraries mentioned on the command line. This option also has an effect on the resolution of symbols in dynamic libraries. This will be the default in the upcoming binutils-2.22 release.

This may result in build errors. More information and recipes how to fix such build errors can be found at NattyNarwhal/ToolchainTransition and the corresponding Debian page.


First enabled in Ubuntu 11.04 (but disabled in the final 11.04 release), and permanently enabled in Ubuntu 11.10. With this option the linker will only add a DT_NEEDED tag for a dynamic library mentioned on the command line, if if the library is actually used.

A common build error with this option enabled is seen when libraries appear on the command line before objects referencing these libraries. More information and recipes how to fix such build errors can be found at NattyNarwhal/ToolchainTransition and the corresponding Debian page.

Failure Triage

catching backtraces from glibc abort

When glibc aborts due to the stack protector or glibc fortification checks, it writes a backtrace to the controlling terminal of the process (/dev/tty) and not stderr. This can lead to unexpected results when running scripts, X, or other applications where stderr and the controlling terminal are not the same location. To have this written to stderr instead, the process needs to run with the environment variable LIBC_FATAL_STDERR_=1 set (yes, there is a trailing underscore in the variable name).

FORTIFY return value checking

When encountering "ignoring return value of ..." build problems due to the FORTIFY flag, it is best to follow this general approach (and to refer to the above individual sections on a case-by-case basis):

  1. If there are examples of error handlers in near-by code, emulate them. An example can be seen with conntrack. This is, obviously, the preferred method of dealing with it.

  2. If there isn't an obvious way to handle the error, then stubbing out an empty handler is the next way to go -- fundamentally, this doesn't improve (or weaken) the quality of the code -- ignoring the return code is what's already happening, so this doesn't change anything. However, what it _does_ do, is allows the FORTIFY option to still be enabled, which means the program will gain the run-time FORTIFY protections.
  3. If there isn't a way to work around the error, and the problem is isolated to a small area of the source code, I've disabled FORTIFY for _only_ those source files, which can be a pain, depending on the package's build methods.

  4. If nothing works, and other people have looked at it, and no one has any ideas about how to work around a problem with FORTIFY, then it's time to disable it for the entire build using the -U_FORTIFY_SOURCE CFLAG.

Now, in all of these situations, upstream needs to be notified. Especially for the #2, where they need to make a larger design decision about how to deal with the unhandled error condition.

Also, in situations where you've had to disable FORTIFY (#3, #4), please document the issue in the "Problems" section below (preferably also with a bug).

Ignoring return code of write()

If the error is ignoring the return code of write() or a similar function then it indicates that the code is not implementing retry support for writes. write(2) says

       If  a  write()  is interrupted by a signal handler before any bytes are
       written, then the call fails with the error EINTR; if it is interrupted
       after  at  least  one  byte  has  been  written, the call succeeds, and
       returns the number of bytes written.

So something like the following should be used to retry when there is a short write (thanks to SteveLangasek)

  do {
      written = write(fd, buf, count);
      if (written == count)
      if (written > 0) {
          buf += written;
          count -= written;
  } while (written >= 0 || errno == EINTR);
  if (written < 0) {
    /* Handle error */

aborts in realpath and getwd

Some applications call realpath(3) and getwd(3) with a buffer that is potentially too small (it should be PATH_MAX long). This is usually a result of not including limits.h or not using PATH_MAX to define the size of the buffer used in the realpath(3) call (there is some confusion here: MAXPATHLEN should be equal to PATH_MAX, but may not be defined without limits.h). So far, xulrunner and linux86 have been found and fixed, so there may be others. For an example of how to fix this, please see the linux86 debdiff.

thread sanitizer vs PIE

If an executable linked with the thread sanitizer fails on startup with a message like

==3581==ERROR: ThreadSanitizer failed to allocate 0x4000 (16384) bytes at address 1ff65735c0000 (errno: 12)

then it needs to be built without PIE (i.e. pass -no-pie to the link step).

Extending FORTIFY

If you are writing libraries or other code where you want to provide mark-up in headers to yell loudly when a function is misused, you can add them yourself.



If the upstream source cannot be reasonably fixed and a package must have compiler flags disabled or some other work-around, please open a launchpad bug, tag it with "hardening-ftbfs", and link to it here along with an explanation of what the problem is:








Valid Code, But Compiler Is Unhappy




Conflicting Goals


Test Suites Not Updated






ToolChain/CompilerFlags (last edited 2016-05-02 02:27:52 by mwhudson)