{"id":420,"date":"2015-03-27T12:25:13","date_gmt":"2015-03-27T12:25:13","guid":{"rendered":"http:\/\/blogs.gentoo.org\/lu_zero\/?p=420"},"modified":"2015-04-17T15:52:23","modified_gmt":"2015-04-17T15:52:23","slug":"again-on-assert","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/lu_zero\/2015\/03\/27\/again-on-assert\/","title":{"rendered":"Again on assert()"},"content":{"rendered":"

Since apparently there are still people not reading the fine man<\/a> page.<\/p>\n

\nIf the macro NDEBUG was defined at the moment was last included, the macro assert() generates no code, and hence does nothing at all.
\nOtherwise, the macro assert() prints an error message to standard error and terminates the program by calling abort(3) if expression is false (i.e., compares equal to zero).
\nThe purpose of this macro is to help the programmer find bugs in his program<\/strong>. The message “assertion failed in file foo.c, function do_bar(), line 1287” is of no help at all<\/strong> to a user.\n<\/p><\/blockquote>\n

I guess it is time to return on security<\/strong> and expand a bit which are good practices and which are misguided ideas that should be eradicated<\/strong> to reduce the amount of Deny Of Service waiting to happen.<\/p>\n

Security issues<\/h2>\n

The term “Security issue”<\/em> covers a lot of different kind of situations. Usually unhanded paths in the code lead to memory corruption<\/strong>, memory leaks<\/strong>, crashes<\/strong> and other less evident problems such as information leaks<\/strong>.<\/p>\n

I’m focusing on crashes<\/strong> today, assume the others are usually more annoying or dangerous, it might be true or not<\/strong> depending on the scenarios:<\/p>\n

If you are watching a movie and you have a glitch in the bitstream that makes the application leak some memory<\/strong> you would not care at all as long you can enjoy your movie. If the same glitch makes VLC to close suddenly a second before you get to see who is the mastermind behind a really twisted plot… I guess you’ll scream at whoever thought was a good idea to crash<\/strong> there.<\/p>\n

If a glitch might get an attacker to run arbitrary code<\/strong> while you are watching your movie probably you’d like better to have your player to just crash<\/strong> instead.<\/p>\n

It is a false dichotomy<\/strong> since what you want is to have the glitch handled properly<\/strong>, and keep watching the rest of the movie w\/out having VLC crashing w\/out any meaningful information for you to know.<\/p>\n

\nErrors must<\/b> be handled, trading a crash<\/b> for something else you consider worse is just being naive<\/b>.\n<\/div>\n

What is assert exactly?<\/h2>\n

assert<\/a> is a debugging facility mandated by POSIX and C89 and C99, it is a macro that more or less looks like this<\/p>\n

\n
#define assert()                                       \\<\/span>\n    if (condition) {                                   \\<\/span>\n        do_nothing();                                  \\<\/span>\n    } else {                                           \\<\/span>\n       fprintf(stderr, "%s %s", __LINE__, __func__);   \\<\/span>\n       abort();                                        \\<\/span>\n    }<\/span>\n<\/pre>\n<\/div>\n
If the condition does not happen crash<\/a>, here the real-life version from musl<\/a><\/p>\n
\n
#define assert(x) ((void)((x) || (__assert_fail(#x, __FILE__, __LINE__, __func__),0)))<\/span>\n<\/pre>\n<\/div>\n
How to use it<\/h2>\n
\nAssert should be use to verify assumptions. While developing<\/strong> they help you to verify if your
\nassumptions meet reality. If not they tell you that should investigate because something is
\nclearly wrong. They are not intended to be used in release builds.
\n– some wise Federico while talking about another language asserts<\/cite>\n<\/p><\/blockquote>\n
Usually when you write some code you might do something like this to make sure you aren’t doing anything wrong, you start with<\/p>\n
\n
int<\/span> my_function_doing_difficult_computations<\/span>(<\/span>Structure<\/span> *<\/span>s<\/span>)<\/span>\n{<\/span>\n   a<\/span> =<\/span> some_computation<\/span>(<\/span>s<\/span>);<\/span>\n   ....<\/span>\n   b<\/span> =<\/span> other_operations<\/span>(<\/span>a<\/span>,<\/span> s<\/span>);<\/span>\n   ....<\/span>\n   c<\/span> =<\/span> some_input<\/span>(<\/span>s<\/span>,<\/span> b<\/span>);<\/span>\n   ...<\/span>\n   idx<\/span> =<\/span> some_operation<\/span>(<\/span>a<\/span>,<\/span> b<\/span>,<\/span> c<\/span>);<\/span>\n\n   return<\/span> some_lut<\/span>[<\/span>idx<\/span>];<\/span>\n}<\/span>\n<\/pre>\n<\/div>\n
Where idx<\/code> in a signed integer, and so a<\/code>, b<\/code>, c<\/code> are with some ranges that might or not depend on some external input.<\/p>\n
You do not want to have idx<\/code> to be outside the range of the lookup table array some_lut<\/code> and you are not so sure. How to check that you aren’t getting outside the array?<\/p>\n
When you write the code usually you iteratively improve a prototype, you can add tests to make sure every function is returning values within the expected range and you can use assert()<\/code> as a poor-man C version of proper unit-testing.<\/p>\n
If some function depends on values outside your control (e.g. an input file), you usually do validation over them and cleanly error out<\/strong> there. Leaving external inputs unaccounted or, even worse, put an assert()<\/code> there is really bad.<\/p>\n
Unit testing and assert()<\/h3>\n
We want to make sure our function works fine, let’s make a really tiny test.<\/p>\n
\n
void<\/span> test_some_computation<\/span>(<\/span>void<\/span>)<\/span>\n{<\/span>\n    Structure<\/span> *<\/span>s<\/span> =<\/span> NULL<\/span>;<\/span>\n    int<\/span> i<\/span>;<\/span>\n    while<\/span> (<\/span>input_generator<\/span>(<\/span>&<\/span>s<\/span>,<\/span> i<\/span>))<\/span> {<\/span>\n       int<\/span> a<\/span> =<\/span> some_computation<\/span>(<\/span>s<\/span>);<\/span>\n       assert<\/span>(<\/span>a<\/span> ><\/span> 0<\/span> &&<\/span> a<\/span> <<\/span>10<\/span>);<\/span>\n    }<\/span>\n}<\/span>\n<\/pre>\n<\/div>\n
It is compact and you can then run your test under gdb<\/strong> and inspect a bit around. Quite good if you are refactoring the innards of some_computation()<\/code> and you want to be sure you did not consider some corner case.<\/p>\n
Here assert()<\/code> is quite nice since we can pack in a single line the testcase and have a simple report if something went wrong. We could do better since assert does not tell use the value<\/strong> or how we ended up there though.<\/p>\n
You might not be that thorough and you can just decide to put the same assert in your function and check there, assuming you cover all the input space properly using regression tests.<\/p>\n
To crash or not to crash<\/h3>\n
The people that consider OK crashing<\/strong> on runtime (remember the sad user that cannot watch his wonderful movie till the end?) suggest to leave the assert enabled at runtime.<\/p>\n
If you consider the example above, would be better to crash<\/strong> than to read a random value from the memory? Again this is a false<\/strong> dichotomy!<\/p>\n
You can expect failures, e.g. broken bitstreams and you want to just check<\/strong> and return a proper failure<\/strong> message.<\/p>\n
In our case some_input()<\/code> return value should be checked for failures and the return value forwarder further up till the library user that then will decide what to do.<\/p>\n
Now remains the access to the lookup table. If you didn’t check sufficiently the other functions you might get a bogus index and if you get a bogus index you will read from random memory (crashing or not depending if the random memory is on an address mapped to the program outside). Do you want to have an assert()<\/code> there? Or you’d rather ad another normal check with a normal failure path?<\/p>\n
An correct answer is to test your code enough so you do not need to add yet another check and, in fact, if the problem arises is wrong<\/strong> to add a check there, or, even worse an assert()<\/code>, you should just go up in the execution path and fix the problem where it is: a non validated input, a wrong “optimization”<\/em> or something sillier.<\/p>\n
There is open debate on if having assert()<\/code> enabled is a good or bad practice when talking about defensive design. In C<\/strong>, in my opinion, it is a complete misuse. You if you want to litter your release code with tons of branches<\/strong> you can also spend time to implement something better and make sure to clean up correctly. Calling abort()<\/code> leaves your input and output possibly in severely inconsistent state.<\/p>\n
How to use it the wrong way<\/h2>\n
\nI want to trade a crash anytime the alternative is memory corruption
\n– some misguided guy<\/cite>\n<\/p><\/blockquote>\n
Assume you have something like that<\/p>\n
\n
int<\/span> size<\/span> =<\/span> some_computation<\/span>(<\/span>s<\/span>);<\/span>\nuint8_t<\/span> *<\/span>p<\/span>;<\/span>\nuint8_t<\/span> *<\/span>buf<\/span> =<\/span> p<\/span> =<\/span> malloc<\/span>(<\/span>size<\/span>);<\/span>\n\n\nwhile<\/span> (<\/span>some_related_computations<\/span>(<\/span>s<\/span>))<\/span> {<\/span>\n   do_stuff_<\/span>(<\/span>s<\/span>,<\/span> p<\/span>);<\/span>\n   p<\/span> +=<\/span> 4<\/span>;<\/span>\n}<\/span>\n\nassert<\/span>(<\/span>p<\/span> -<\/span> buf<\/span> ==<\/span> size<\/span>);<\/span>\n<\/pre>\n<\/div>\n
If some_computation()<\/code> and some_related_computation(s)<\/code> do not agree, you might write over the allocated buffer! The naive person above starts talking about how the memory is corrupted by do_stuff()<\/code> and horrible things<\/strong> (e.g. foreign code execution) could happen without the assert()<\/code> and how even calling return<\/code> at that point is terrible and would lead to horrible horrible things.<\/p>\n
Ok, NO<\/strong>. Stop NOW<\/strong>. Go up and look at how assert is implemented. If you check at that point that something went wrong, you have the corruption<\/strong> already. No matter what you do, somebody could exploit it depending on how naive you had been or unlucky.<\/p>\n
Remember: assert()<\/code> does do I\/O<\/strong>, allocates memory<\/strong>, raises a signal<\/strong> and calls functions<\/strong>. All that you would rather not do when your memory is corrupted is done by assert()<\/code>.<\/p>\n
You can be less naive<\/strong>.<\/p>\n
\n
int<\/span> size<\/span> =<\/span> some_computation<\/span>(<\/span>s<\/span>);<\/span>\nuint8_t<\/span> *<\/span>p<\/span>;<\/span>\nuint8_t<\/span> *<\/span>buf<\/span> =<\/span> p<\/span> =<\/span> malloc<\/span>(<\/span>size<\/span>);<\/span>\n\nwhile<\/span> (<\/span>some_related_computations<\/span>(<\/span>s<\/span>)<\/span> &&<\/span> size<\/span> ><\/span> 4<\/span>)<\/span> {<\/span>\n   do_stuff_<\/span>(<\/span>s<\/span>,<\/span> p<\/span>);<\/span>\n   p<\/span>    +=<\/span> 4<\/span>;<\/span>\n   size<\/span> -=<\/span> 4<\/span>;<\/span>\n}<\/span>\nassert<\/span>(<\/span>size<\/span> !=<\/span> 0<\/span>);<\/span>\n<\/pre>\n<\/div>\n
But then, instead of the assert you can just add<\/p>\n
\n
if<\/span> (<\/span>size<\/span> !=<\/span> 0<\/span>)<\/span> {<\/span>\n    msg<\/span>(<\/span>"Something went really wrong!"<\/span>);<\/span>\n    log<\/span>(<\/span>"The state is %p"<\/span>,<\/span> s<\/span>-><\/span>some_state<\/span>);<\/span>\n    cleanup<\/span>(<\/span>s<\/span>);<\/span>\n    goto<\/span> fail<\/span>;<\/span>\n}<\/span>\n<\/pre>\n<\/div>\n
This way when the “impossible”<\/em> happens the user gets a proper notification and you can recover cleanly and no memory corruption ever happened.<\/p>\n
Better than assert<\/h2>\n
Albeit being easy to use and portable assert()<\/code> does not provide that much information, there are plenty of tools that can be leveraged to get better reporting.<\/p>\n