Compiler options for security

What is the current recommended level of error checking used when compiling maidsafe? I found a list of compiler options recommended by Doc Shankar (of IBM):

gcc -Werror -Wall
-Wmissing-prototypes -Wmissing-declarations
-Wstrict-prototypes -Wpointer-arith
-Wwrite-strings -Wcast-qual -Wcast-align
-Wbad-function-cast
-Wformat-security -Wformat-nonliteral
-Wmissing-format-attribute
-Winline

On top of this -W -pedantic and -funsigned-char have also been recommended.

Are these still a good idea when doing c++11?

Yes we use the highest possible levels on clang gcc and level 4 for msvc (the max is mental and MS code does not pass). You can see the flags here MaidSafe-Common/common_flags.cmake at master · dirvine/MaidSafe-Common · GitHub

Importantly we also have sanitiser runs built in so if your compiler supports ubsan it is on by default. You can also pass -DCMAKE_BUILD_TYPE=Tsan or Msan or Asan and get the relevant sanitiser run (these all passing is a terrific sign of code quality).

In addition we treat all warnings as errors and stop the compile until a dev fixes the warning. This seems harsh but in fact saves a tone of silly mistakes creeping in. This means all compiles should be clean and warning free.

No third party code we have used is this pedantic and we turn down these checks for cryptopp/boost/gtest etc. given time we would patch all these to the same level at least and one day I would hope we can or sponsor people to do hat.

This is all great and is acceptable for me anyway, it does not, however, fix any logic errors in fundamental algorithms, for that we use code review and I am very focused on less code, very few raw loops and get the core algorithm correct, so when there are a bunch of ifs and loops it is treated as bad code in need of refactor, whether it passes tests or not.

We are almost complete automating jenkins/github integration for automatic cross platform runs of tests and sanitisers etc. The Qa guys are looking at baseline and checking coverage to ensure at least coverage is maintained per commit of code, again not a silver bullet but on way.

6 Likes

Just noted the security aspect, there are several security options (again no silver bullet) stuff like stack protection etc. are all very good, kernel capabilities are another are that can be used to improve process separation but that really another matter. In terms of flags it is a case of what works in your implementation and can be driven by 3rd party libs (STACK_PROTECTION was hard to do a few years back as well as a few others as the supplied kernel code was not compiled with it).

Please check out our code (use “make VERBOSE=1”) and see what flags we use and any feedback is welcomed, although people can go flag mental (I have at times). Shout if something looks weird. or lacking in any way though, we will create a task and investigate (we don’t change flags much unless very obvious)).

Thanks again

3 Likes