[Cryptography] How programming language design can help us write secure crypto code

[Jonathan Thornburg]

Peter Gutmann wrote:
> Purely from
> reading the gcc docs (so you can't compile test code with it to see what
> happens, and you can't answer this if you already know what'll happen), can
> someone tell me what they think this will do if applied to the following code:
> 
> __attribute__(( nonnull 1 )) \
> int double( int *ptr )
>   {
>   if( ptr == NULL )
>     return( -1 );
>   return( *ptr * 2 );
>   }
> 
> [...]
>   thing = double( thingPtr );
> [...]

Peter later quoted the documentation in question:
> The nonnull attribute specifies that some function parameters should be non-
> null pointers. For instance, the declaration:
>
>         extern void *
>         my_memcpy (void *dest, const void *src, size_t len)
>               __attribute__((nonnull (1, 2)));
>
> causes the compiler to check that, in calls to my_memcpy, arguments dest and
> src are non-null. If the compiler determines that a null pointer is passed
> in an argument slot marked as non-null, and the -Wnonnull option is enabled,
> a warning is issued. The compiler may also choose to make optimizations
> based on the knowledge that certain function arguments will not be null.

Ok, I'll bite.  The first thing I think gcc (or any other C compiler)
will do with the code in question is complain that trying to declare/define
a function named 'double' isn't allowed, because 'double' is a reserved
keyword.

Once we rename the function, then based (solely) on the documentation Peter
quoted, I expect the semantics of the function to be
* If passed a non-NULL pointer p, return 2 * (*p)
* If passed a NULL pointer, then undefined behavior occurs: I have
  promised the compiler that this pointer will *always* be non-NULL,
  and explicitly given the compiler license to optimize based on this
  assumption.  I've then then broken my promise, so all bets are off.
  This is the key thing: I've lied to the compiler, so I should expect
  lots of trouble.  In particular, I do NOT expect that the code is
  made "safe" by the attempted guard code
>   if( ptr == NULL )
>     return( -1 );
  since I've explicitly promised to the compiler that this guard
  can *never* be satisfied, and I've given the compiler explicit
  license to optimize (e.g. dead-code-removal) based on that promise.
  If the code containing the NULL-pointer call includes a /dev/nasal-demon
  driver, then I expect that nasal demons may appear.  



On Sun, Nov 01, 2015 at 04:20:09AM +0000, Peter Gutmann wrote:
> As
> I've already said twice now, the various people I've talked to about this
> assumed that what the annotation did was warn about inadvertent null pointer
> use.  It's not a large sample, but of that sample, 100% assumed from reading
> the docs that it did more or less the opposite of what it actually does.

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jthorn at astro.indiana-zebra.edu>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"