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

[Bill Frantz]

Let me go a bit meta here. Hopefully I will be able to answer 
Watson's questions as I go along.

I must ask what we are trying to accomplish with a 
compiler/development system. I hope our goal is to help 
programmers, many of whom will not be true language experts, 
write code that is robust and correct.

To accomplish this goal, I think we need clear communication 
between the programmer and the development system. Part of that 
comes from the language standard, but compilers should warn 
about undefined behavior and common errors (like if (a=0)... gcc 
warns about). Ideally, the only observable changes from 
increasing the optimization level of a compiler would be slower 
compiles and faster object execution.

When I read Peter's challenge to define the behavior of:
           extern void *
           my_memcpy (void *dest, const void *src, size_t len)
             __attribute__((nonnull (1, 2)));

My first reaction was, of course we are defining a pre-condition 
for the correct execution of my_memcpy. The compiler will try to 
prove the parameters are not null and generate warnings if it 
could not complete these proofs.

But, of course, given the tone of this discussion thread, this 
interpretation seemed very unlikely. However, it would be a 
realistic interpretation if the compiler was trying to help 
non-expert, or inattentive expert programmers write correct code.


On 11/1/15 at 3:49 AM, watsonbladd at gmail.com (Watson Ladd) wrote:

>Have you ever read Appel's compiler book?

No. He's after my time. I lost interest in the details of 
compiler code generation about 1970-1775 when he was 10 or 15 
years old. But, I shouldn't have to be a compiler student to use 
one safely.


>The myth of
>"machine-independent assembler" ignores even the most basic of tricks
>like register allocation.  For instance every assembler coder will
>omit redundant loads and stores, and so will a compiler. But this
>breaks the relation between stack locations and variables, in some
>cases quite badly. There are lots of other examples, like instruction
>scheduling, strength reduction, etc. A lot of the "machine independent
>compiler myth" stems from the poor quality of C compilers.  Why do you
>care what the assembly looks like, instead of what it does?

I don't understand your point here. How is C not a machine 
independent low level language, like assembler is a machine 
dependent low level language? Yes, C compilers do memory address 
assignment, as do assemblers. They also do register assignment 
which assemblers normally don't do. Still their target 
application areas (e.g. operating systems, drivers, etc.) are 
the same.

At the level we're discussing, we care about what the object 
code does, or more importantly omits doing, not how it does it. 
Most of the discussion centers around the compiler removing 
tests the programmer inserted, not issues of memory or register 
address assignment.


>... But this whole complaint that "the compiler
>doesn't do what I think it should" completely ignores what compilers
>for some languages have *always* done.

This statement is clearly wrong for most languages. In the first 
compiler I used, FORTRANSIT (a subset of Fortran) for the IBM 
650, the compiler didn't do any optimizations. It was 4 passes 
on punch cards with punch card intermediate storage. I was a 
wonder it worked at all.

I remember looking at the object code of the IBM 360 PL/I 
compiler at it's highest optimization level sometime around 
1970. It was quite clever using a memory to memory move to 
initialize two integer variables. However it also stored a 
register into a memory location and reloaded the same register 
from that memory location in the next instruction. Not the best 
optimization imaginable.

IBM Fortran H was one of the first compilers to generate highly 
optimized object code. One of the jokes about it was that every 
time they fixed a bug, they removed an optimization.


I think the problem here is mostly social. While we could 
tighten up the C standard for signed integer overflow, that's 
only a bandaid.

I know I'm a poor expert programmer union man for wanting to 
help non-union people write correct, safe code. I should be 
protecting union jobs.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        | Re: Computer reliability, performance, and security:
408-356-8506       | The guy who *is* wearing a parachute is 
*not* the
www.pwpconsult.com | first to reach the ground.  - Terence Kelly