[Cryptography] Ada vs Rust vs safer C

[Ron Garret]

On Sep 17, 2016, at 10:41 AM, Watson Ladd <watsonbladd at gmail.com> wrote:

> > 2.  Treating all lvalues as if they were volatile (i.e. not even trying to optimize anything, just a completely straightforward translation of C into assembly) would likewise be a huge win.
> 
> Has this lead to security bugs? No. Forget the nonsense of secure erasure and realize operating systems clear memory between users and programs.

This has nothing to do with secure erasure, this has to do with avoiding side-channel timing attacks introduced by the compiler eliding what it thinks is dead code.

> > 3.  If you really want to win big, have your compiler distinguish internally between T* v and T v[c], and likewise distinguish between *(v+offset) and v[offset], and add bounds checking in the latter case.  Yes, this violates the C standard, but so what?  The C standard is stupid.
> 
> Please cite chapter and verse.

Are you seriously disputing that C defines x[y] and (x+y) to be equivalent operations?

> Bounds checking is legal as the C memory model is not a flat address space.

The legality of bounds checking and the flatness of the address space are two completely orthogonal issues.

> The keyword is derived pointer: you can only legitimately access a memory region through pointers created certain ways.

That is certainly true, but that’s not the point.  The point is whether or not the compiler can tell whether or not what you are doing is “legitimate”.

> > 4.  If you really REALLY want to win big, define a new language that is just like C but where v[offset] and *(v+offset) are NOT equivalent operations, and deprecate the latter.
> 
> What semantics do you want here?

I want *all* data access (reads and writes) to be checkable, either at compile time or run time, to make sure that they only access memory that has been properly allocated.

rg