Somebody Else’s Problem

The late, great Douglas Adams described the “SEP field”.  Something may be huge and blindingly obvious and right in front of you, but it’s somebody else’s problem so you don’t see it.

I’ve seen a bug report for a cryptographic function.  Nothing too unusual there you might think, but there’s a twist.  Any fix we could ever implement would not be a fix, but rather an ugly hacked workaround for somebody else’s problem.

Let me explain.  The bug concerns memory that may have contained secrets.  To free it after use, we wipe the potentially-sensitive data:

    memset(buf, 0, bufsize);
    free(buf);

Now the bug there isn’t in our code, it’s in the fact that some compilers and settings might optimise out the memset leaving the sensitive data in freed memory.

How to fix that?

Introduce dummy code that re-uses the buffer after memset?  Not just horribly inefficient, but difficult to guarantee that can’t also be optimised out, either by the compiler or by another developer who sees this useless code.

OK, what about a nightmare of #ifdefs to target compilers?  Erm, no thanks.  If something’s in a widely-supported standard like ANSI or POSIX, the last thing we want is to replace it with a maintenance nightmare of proprietary hacks.

So fix the build to disable optimisation compiling the source file in question?  Not really a solution: downstream folks building and distributing the software may have their own build setups independent of ours.

An altogether better solution-in-principle would be some #pragma that could be standardised across compilers and could disable optimisations within a source file.  It could maybe affect the entire source file that declares it, or ideally it could scope arbitrary sections of code in the manner of #if / #ifdef.  But that’s Somebody Else’s Problem.