[Cryptography] Buffer Overflows & Spectre

John Denker jsd at av8n.com
Thu Nov 22 13:01:25 EST 2018


On 11/19/18 7:50 AM, Henry Baker wrote:

>> We've been undone by our own hardware,

On 11/21/18 5:45 PM, Nemo wrote:

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

That example supports Henry's point that we have been sold
down the river by HW manufacturers.  The VAX was designed
in the mid-1970s and included a bit in the status register
to turn on trapping on integer overflow.

To this day, x86 processors do not have such a bit.  There
is an INTO instruction that allows you to check for overflow,
but you have to use the instruction following every operation
that might overflow, which means there is a measurable cost
to using it, which means there is temptation to not use it.

Yet manufacturers have the audacity to say that even though
it is economical to put more and more transistors on a chip,
they can't figure out what to do with them, other than to
run multiple cores in parallel.  Give me a break.

> 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".

That is a very dangerous philosophy -- especially when it
comes to security.  It supports Henry's point that language
designers have shown a lack of wisdom in deciding who pays
for what, when.

People *always* pay, either for security or for the lack
thereof.  For example, in 2016 the Democratic National
Committee chose not to pay for two-factor authentication
for their remotely-accessible servers.  They wound up paying
a bitter price for the lack thereof.

> 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.

That's literally true but highly misleading.  We all know
that it is possible to write bad code in any language.  It
is also "possible" in principle to write good code in any
language, if you are skillful enough and work hard enough.
HOWEVER, some languages make it a lot easier than others.

> Or use a language that takes a performance hit everywhere to give
> defined behavior everywhere. 

No, not everywhere.  As Knuth put it, premature optimization
is the root of all evil.  The smart approach is to take the
performance hit in the 99% of the code where it absolutely
does not matter.  Then hire an expert coder and a language
lawyer to deal with the 1% where low-level pounding on the
bare metal might actually matter.

> Have you tried taking your complaint to someone who works on compilers?

Yes.

> 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.

No, not invariably.  Some language designers do not assume
that everyone who doesn't share their background must be
stupid.  Some of them listen respectfully.  Some of them
proactively solicit suggestions.  Some of them systematically
study the errors that show up in production code, and then
brainstorm ways to improve the language.


More information about the cryptography mailing list