There will be a new option in gcc 4.9 named
-fstack-protector-strong , which offers an improved version of
-fstack-protector without going all the way to
-fstack-protector-all . The stack protector feature itself adds a known canary to the stack during function preamble, and checks it when the function returns. If it changed, there was a stack overflow, and the program aborts. This is fine, but figuring out when to include it is the reason behind the various options.
Since traditionally stack overflows happen with string-based manipulations, the default (
-fstack-protector), only includes the canary code when a function defines an 8 (
--param=ssp-buffer-size=N, N=8 by default) or more byte local character array. This means just a few functions get the checking, but they re probably the most likely to need it, so it s an okay balance. Various distributions ended up lowering their default
--param=ssp-buffer-size option down to 4, since there were still cases of functions that should have been protected but the conservative gcc upstream default of 8 wasn t covering them.
However, even with the increased function coverage, there are rare cases when a stack overflow happens on other kinds of stack variables. To handle this more paranoid concern,
-fstack-protector-all was defined to add the canary to all functions. This results in substantial use of stack space for saving the canary on deep stack users, and measurable (though surprisingly still relatively low) performance hit due to all the saving/checking. For a long time, Chrome OS used this, since we re paranoid. :)
In the interest of gaining back some of the lost performance and not hitting our Chrome OS build images with such a giant stack-protector hammer, Han Shen from the Chrome OS compiler team
created the new option
-fstack-protector-strong, which enables the canary in many more
conditions:
- local variable s address used as part of the right hand side of an assignment or function argument
- local variable is an array (or union containing an array), regardless of array type or length
- uses register local variables
This meant we were covering all the more paranoid conditions that might lead to a stack overflow. Chrome OS has been using this option instead of
-fstack-protector-all for about 10 months now.
As a quick demonstration of the options, you can see this example program under various conditions. It tries to show off an example of shoving serialized data into a non-character variable, like might happen in some network address manipulations or streaming data parsing. Since I m using
memcpy here for clarity, the builds will need to turn off FORTIFY_SOURCE, which would also notice the overflow.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
struct no_chars
unsigned int len;
unsigned int data;
;
int main(int argc, char * argv[])
struct no_chars info = ;
if (argc < 3)
fprintf(stderr, "Usage: %s LENGTH DATA...\n", argv[0]);
return 1;
info.len = atoi(argv[1]);
memcpy(&info.data, argv[2], info.len);
return 0;
Built with everything disabled, this faults trying to return to an invalid VMA:
$ gcc -Wall -O2 -U_FORTIFY_SOURCE -fno-stack-protector /tmp/boom.c -o /tmp/boom
$ /tmp/boom 64 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault (core dumped)
Built with FORTIFY_SOURCE enabled, we see the expected catch of the overflow in
memcpy:
$ gcc -Wall -O2 -D_FORTIFY_SOURCE=2 -fno-stack-protector /tmp/boom.c -o /tmp/boom
$ /tmp/boom 64 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
*** buffer overflow detected ***: /tmp/boom terminated
...
So, we ll leave FORTIFY_SOURCE disabled for our comparisons. With pre-4.9 gcc, we can see that
-fstack-protector does not get triggered to protect this function:
$ gcc -Wall -O2 -U_FORTIFY_SOURCE -fstack-protector /tmp/boom.c -o /tmp/boom
$ /tmp/boom 64 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault (core dumped)
However, using
-fstack-protector-all does trigger the protection, as expected:
$ gcc -Wall -O2 -U_FORTIFY_SOURCE -fstack-protector-all /tmp/boom.c -o /tmp/boom
$ /tmp/boom 64 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
*** stack smashing detected ***: /tmp/boom terminated
Aborted (core dumped)
And finally, using the gcc snapshot of 4.9, here is
-fstack-protector-strong doing its job:
$ /usr/lib/gcc-snapshot/bin/gcc -Wall -O2 -U_FORTIFY_SOURCE -fstack-protector-strong /tmp/boom.c -o /tmp/boom
$ /tmp/boom 64 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
*** stack smashing detected ***: /tmp/boom terminated
Aborted (core dumped)
For Linux 3.14, I ve
added support for
-fstack-protector-strong via the new
CONFIG_CC_STACKPROTECTOR_STRONG option. The old
CONFIG_CC_STACKPROTECTOR will be available as
CONFIG_CC_STACKPROTECTOR_REGULAR. When comparing the results on builds via
size and
objdump -d analysis, here s what I found with gcc 4.9:
A normal x86_64 defconfig build, without stack protector had a kernel text size of 11430641 bytes with 36110 function bodies. Adding
CONFIG_CC_STACKPROTECTOR_REGULAR increased the kernel text size to 11468490 (a +0.33% change), with 1015 of 36110 functions stack-protected (2.81%). Using
CONFIG_CC_STACKPROTECTOR_STRONG increased the kernel text size to 11692790 (+2.24%), with 7401 of 36110 functions stack-protected (20.5%). And 20% is a far-cry from 100% if support for
-fstack-protector-all was added back to the kernel.
The next bit of work will be figuring out the best way to detect the version of gcc in use when doing Debian package builds, and using
-fstack-protector-strong instead of
-fstack-protector. For Ubuntu, it s much simpler because it ll just be the compiler default.
2014, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Now that the madness is mostly
over, I have some time to catch up on reading my newspaper.
Last week, one article in De Standaard talks about the
nuclear weapons on Belgian soil which officially didn't exist (until
wikileaks proved otherwise) and which are now apparently going to be
modernized. The newer model would be "nuclear precision weapons".
Ignoring the question of whether today's world still requires nuclear
bombs (this may or may not be true, I don't care), I question the logic
which leads to that phrase. A nuclear weapon is a weapon of mass
destruction. By definition, a weapon of mass destruction causes
collateral damage. By definition, a precision weapon is a weapon that
does not cause collateral damage or, at the very lease,
where every effort is made to limit the amount of collateral damage.
Even the very first nuclear bombs were capable of destroying entire
cities. Today's nuclear weapons, even the smaller ones, are far more
powerful than those.
Don't get me wrong: I'm not a peace activist. In fact, I have been
contracted by companies who produce military equipment, and don't feel
bad about that. But to claim that it is possible to create "nuclear
precision weapons" is to deceive oneself. A nuclear weapon is
not very precise.
This weekend I attended FOSDEM, as I did for the past 4 years. As always, it
was a great experience, even if most of the talks I attended were not so
interesting.
One of the great things about these events, is to get together with other Free
Software enthusiasts. One of them introduced me to the new kid on the block:
Yesterday was pretty crazy busy. I woke up a little bit late because I
didn't have Zoe, and decided to head down to 
When you run Puppet, it is very important to monitor whether all nodes have an uptodate catalog and did not miss the last year of changes because of a typo in a manifest or a broken cron-script. The most common solution to this is 
A new major release 0.11.0 of
After years under Mako s loving care, iron-blogger is now under 
Couple of weeks ago I was in the situation of having to setup up a new laptop. I decided to go with wheezy s DVD installer. So far so good. I didn t expect (somewhere in the lies-I-tell-myself dept.) to have GNOME as the default Debian desktop. However after install I ve figured it was the new GNOME3 everybody was talking about. Before that I ve seen it in Ubuntu systems used by my classmates. I thought yeah, OK GNOME3, I think that s fine for them as a Linux desktop. Turns out that I ve started using the Debian desktop aka GNOME3 and noticed that it was not as bloated as the Ubuntu desktop I ve seen before looked, so I sticked with it, (I thought for a while).
Turns out that I did like this new so called GNOME3, the non-window based but an application-based system (that is something that sticks in my head). I liked the way it makes sense as a desktop system, like when you look for applications, documents, connect to networks, use pluggable devices or just configure stuff every time with less and less effort. Good practices and concepts learned from Mac OS X-like environments and for sure taking advantage of the new features the Linux kernel and user-space environment got over the years. So, like one month later I stick with it and it makes sense for me to keep it. I had no chance to try the latest XFCE or KDE, my default choices before this experience. Kudos GNOME team, even after the depictions you guys had on GNOME Shell; as I learned.
This whole situation got me into some pondering about the past of the Linux user experience and how we in the community lead people into joining. I remember that when I guy asked: how do I configure this new monitor/VGA card/network card/Etc? the answer was in the lines of: what is the exact chipset model and specific whole product code number that your device has? Putting myself in the shoes of such people or today s people I d say: what are you talking about? what it is a chipset? I mean, like it was too technical that only one guy with more than average knowledge could grasp. From a product perspective this is similar for a car manufacturer tell to a customer to look for the exact layout or design your car s engine has, so that they are able to tell whether is the 82 s model A or 83 s model C. Simplicity on naming and identification was not in the mindset of most of us.
This is funny because as technology advances it also becomes more transparent to the customer. So, for instance, today s kids can become really power users of any new technology as if they had, indeed, many pre-set chipsets in their brain. But when going into the details we had to grasp few years ago they have some hard time figuring out the complexity of the product that presents itself on this clean and simple interface. New times, interesting times. Always good to look back. No, I m not getting old.
My friend 
The