[Cryptography] Buffer Overflows & Spectre

[Nemo]

A little bit afield, but I believe discussions of secure coding
w.r.t. programming languages is on-topic.

Jon Callas <jon at callas.org> writes:

> I think it’s far more like the present mess with C compilers where the
> compiler people have gone and created so much undefined behavior that
> C is no longer a low-level language.

This is close to "not even wrong" territory.

The C language is defined by a precise specification ratified as an
International Standard in 1990. (And then extended in 1999 and 2011, but
C90 remains the most popular flavor.)

Everything that was defined in 1990 is still defined today. Everything
that is undefined today was already undefined in 1990. Neither "compiler
people" nor anyone else has added any undefined behavior in 30 years,
nor could they.

You are complaining that a piece of code from 1990, whose behavior was
definitely never defined by the language, acts differently under
different compilers over the years.

Have you tried taking your complaint to someone who works on compilers?
You would not be the first. The interaction invariably goes like this:
Inexperienced C or C++ programmer is surprised by some optimization and
petitions compiler authors that said optimization should be
disallowed. Compiler authors explain they have a decades-old spec
clearly stating exactly what is and is not allowed, and asks petitioner
what they would like to change, exactly.

Petitioner either turns out not to know except in the vaguest possible
way (80%), or to be asking for something that would harm performance for
everyone everywhere (20%). Also every petitioner has a different answer.

Perhaps the most deeply-embedded philosophy in the DNA of the C/C++
language designs is "you do not pay for what you do not use". Security
concerns, like everything else, fall under this rubric. If you cannot
handle this, you are using the wrong language.

There is significant empirical evidence that the security of any
software has everything to do with who wrote it and almost nothing to do
with the implementation language. In the case of C/C++, it is certainly
possible to adopt a style that enables secure code. See OpenBSD for a
real-world example.

You did not give even one example of what you mean, so I will pick a
typical one: Integer overflow.

What should happen if the mathematical sum of two positive signed
integers does not fit in an int? (BTW, how many bits should that be,
exactly?) If you care about correctness -- and thus security -- there
are only three possible answers:

  1) Don't do that.
  2) An exception should be raised.
  3) The width of the result should grow to hold the sum.

There are approximately zero cases where "produce a negative result" is
what the programmer actually wants.

The C/C++ language spec goes with option (1). If you want (2) or (3),
you can use a library to get them (see Microsoft's SafeInt and
Boost.Multiprecision, respectively).

You will find the same is true for all forms of undefined behavior:
Defining it in a sane way would not be performant, and defining it in a
performant way would not be sane. Thus "don't do that or use a library".

Or use a language that takes a performance hit everywhere to give
defined behavior everywhere. There are plenty of them.

 - Nemo