[Cryptography] Ada vs Rust vs safer C

Arnold Reinhold agr at me.com
Mon Sep 19 14:25:00 EDT 2016

> On Sep 18, 2016, at 12:31 PM, Tom Mitchell <mitch at niftyegg.com> wrote:
> On Fri, Sep 16, 2016 at 1:31 PM, Arnold Reinhold <agr at me.com <mailto:agr at me.com>> wrote:
> In the recent thread on safe erasure in C,  much was made of better languages including Ada and Rust. But there is a vast mount of code already written in C. Converting all of it or even a large fraction seems hopeless
> ..... 
> Not hopeless,
> The problem is large yet calling convention for the  ABI of existing compilers
> allow incremental  functionality to be coded in a "better language".  To start
> GCC and CLANG use a common calling convention.
> So to start, code modules of interest in a "better" language 
> and use a common ABI link to the larger body of system code and libraries.
> Over time one layer at a time replace the dependencies.
> At thes end point C is left behind and the "better" tool chain
> is responsible for the entire program.
> It may take a couple starts to learn what a "better" language
> and tool chain is.    Often the objections and advantages
> are best understood when used for real so start.

That is not an unreasonable approach, one that Apple seems to be taking with Swift, but I don’t think it is likely to work in the majority of cases. There are too many software systems committed to C and C++. Many projects these days depend on multiple libraries over which they have little control. The often expect to benefit from ongoing development of those libraries. And C has almost a lock on embedded systems development. Rust seems to be largely ignoring embedded systems. There is an experimental project, zink.rs, trying to make it work for ARM that has a blinking LED program working, the embedded equivalent of “Hello world.”. Efforts to make Rust work for the AVR architecture seem stalled. ADA was designed for embedded systems, but it is unloved and doesn’t seem to be used much outside of situations where its use in mandated. Embedded system, especially Internet of Things, has arguably the most critical need for improved security.

So I think an effort to make C more security friendly is warranted. I think this is primarily an organizational problem, not a technical one. As is obvious from this thread there have been many past attempt to solve C’s insecurity, with very limited success. C11 at least has memset_s. What’s missing is some form of governance, starting with a clearer definition of the project. Here is what I had in mind: 

Since the target is the vast amount of existing C code, the proposed compiler must be fully compatible with the C specs (C99? C11?), with the possible exception of one or a few new reserved words, e.g. for a zeroizable type. 

Ab initio safety improvements would consist of clarification of undefined C behaviors to make unsafe code generation less likely. For example assuming twos complement arithmetic. 

For data marked zeroizable, the compiler would minimize copies and keep track to insure they are erased after they are no longer needed in all situations. (That might be the linear type mentioned, I don’t want to prejudge technical solutions at this point.)

In addition memset_s support, maybe statements of the form x=0; should never be optimized out. Neither would asserts. 

Invalid memory access is a great cause of concern in C and a vast amount of work has already been done. I would expect to adopt the best-of-breed approaches on a opt in basis, with detect & warn, suggest corrections and automatic remediation as options.

A major focus would be designing for strict configuration management. It should be possible for source code version management tools to completely control how the compiler is invoked for each source module. The goal should be that once a code module is tested and approved, the object code should never change without a new approval process. If that means compiling to assembler code and then storing the assembler file as the primary source document with the C source as a reference, so be it. Maybe add electronic signatures to source code modules. There also needs to be some way of avoiding the Hobson's choice of turning off warnings or being flooded by them. Maybe all the hooks to do this are already present and all that is needed is a best practices document. Whatever. Effective change control is a necessity in any sane engineering discipline.

To me the question is what kind or organizational; effort is needed to make this work and get compiler people thinking about security as something that they wish to assist with?

Arnold Reinhold

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160919/28fc42d3/attachment.html>

More information about the cryptography mailing list