Re: Heartbleed

[Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>]

On 2014-04-12, Shark8 <OneWingedShark@gmail.com> wrote:
> On 11-Apr-14 13:33, Simon Clubley wrote:
>>
>> C, even in 2014, is used for critical libraries so there's clearly a
>> place for a simpler language with comparable functionality to C, but
>> with the functionality done in a type safe way.
>>
>> Sadly, I agree with a previous post that it's unlikely to be Ada because
>> of the vast range of systems these libraries run on and because of the
>> major issues around getting Ada (which in this context really means GNAT)
>> to run in a new environment.
>
> Well, there are several of us who are looking into ameliorate that 
> condition w/ new open-source compilers.
>

Will these new compilers be easy to port to a new environment or will
the size and functionality of the Ada language make porting a major task ?

>> What may be a viable option would be if a simpler Wirth style language
>> existed and whose compiler generated object code compatible with gcc
>> and used binutils for it's assembling/linking phase.
>
> Oberon?
>

Something based on one of the Oberon variants is _exactly_ the kind of
thing I was thinking of. I would modify some of the syntax elements to
make them more Ada like however.

You know, Oberon-14 sounds like a nice name for a new programming
language. :-)

>> That compiler would be written in plain C making it easier to bring up
>> in a new environment with foreign compilers.
>
> I disagree; the compilers we build should *not* be dependent on C. -- 
> There are too many easy-to-make errors, mistakes, and 
> implementation-dependencies to really ensure that such a compiler is 
> good. Indeed, I would argue that we need compilers built on 
> formal-methods and verified to be correct.
>

Careful; you need to think of the big picture here.

The goal here is to replace C when writing libraries which are used on
a vast range of platforms (like OpenSSL). That simply isn't going to
happen unless the compiler runs on the same range of platforms C compilers
currently run on and unless the code generator in the compiler generates 
code for the same range of targets the C compilers currently do.

You can have all the nice formally verifiable capable implementation
languages you want, but that does nothing to challenge C's status in the
market place unless the above conditions are met. This is _exactly_
the situation we are in with Ada right now and why everyone uses C instead
of Ada or SPARK.

Also, you only need to implement the core compiler in C; the RTL and
support libraries for the language can be pretty much implemented in the
language itself.

You can assume there's a C compiler and binutils on the host platform,
but you can't really assume much else.

>> For the libraries C is being used for and for which the security issues
>> exist, you don't need a huge Ada style runtime with a huge Ada style
>> language functionality that's damned difficult to port to a new
>> environment.
>
> I wonder about that; is the runtime that difficult to port? What about 
> having "staged" runtimes, with minimal, reduced, and nominal 
> functionality? (Perhaps using the restriction pragmas...)
>
> Also, couldn't such a system be made so that the *really* system 
> dependent stuff is all hidden in a package-body and [relatively] easy to 
> port?
>
> eg
> Minimal : No tasking or protected objects, or unconstrained functions 
> allowed.
> Reduced : No Tasking and Protected objects; but unconstrained functions 
> are allowed.
> Normal  : Everything.
>

People like Luke who have tried this in the past always seem to run up
against various random issues which can make things seem fragile. I've
read Luke's change logs in the past and have seen how much effort he's
expended trying to get it running on just one or two bare metal platforms.

>> However, to stand a chance of displacing C you need a compiler which runs
>> in the same range of environments as C does and you need libraries written
>> using this language to be _easily_ callable from C and the other languages
>> which currently use C libraries. That's the reality anyone wanting to
>> replace C is facing.
>
> I don't know -- it might be time for professionals concerned w/ security 
> to make a clean break and just use something else -- Eiffel is, from 
> what I understand, ideal for library-writing with its heavy emphasis on 
> interfaces [and design by contract].
>

That simply, absolutely, is not going to happen.

The only chance you have of displacing C is to allow libraries written in
your new language to be linked against just as easily as C libraries
currently can be.

No corporation or other entity is going to throw away all it's existing
code just to use a new library. Either libraries written in your new
language can be made to fit into the existing application code base or
the new library will not be used in any major way.

For a specific example: if you want to write a new SSL library in, say,
Oberon-14, it has to plug into the existing code which uses the existing
OpenSSL library or it simply will _not_ get used. This includes your new
library needing to run on the vast range of platforms the OpenSSL library
runs on, including those el-cheapo ADSL modems/routers and other commodity
devices.

That's the real world reality you are up against if you want to replace C.

However, once you have your foot in the door, you can then start gradually
using your new type safe language in more and more libraries and even
application code.

In that way, people don't have to start making major investments just to
try out your new language. This means it's much more likely they are
going to explore libraries written in it if they feel like they can stay
in control of the process and feel they can easily reverse the process
if it doesn't work out as expected.

>> BTW, once you have people exposed to type safe programming, then maybe
>> you can introduce them to Ada for the large projects. One of the major
>> revelations for me over Heartbleed was seeing people discuss the need
>> for a safer language and immediately jump to languages like Java.
>
> Hm, good point.
> Ada has some *REALLY* good features when it comes to 
> programming-in-the-large -- the YF-22 integration is astounding:
> 12 major avionics subsystems, across 650 Ada modules containing millions 
> of lines of code, coded in 8 geographically distinct locations, took 
> *three days!*
>
> Source: http://archive.adaic.com/docs/present/engle/comments/tsld033.htm
>
>> The idea that there might be a option in between, a traditional compiled
>> language which offered type safe functionality simply didn't seem to
>> occur to them. It's as if C, C++ and Java are the only languages most
>> people seem to have heard about.
>
> Yeah -- that's rather disgusting. I blame the prevalence of c-style 
> languages as well as universities 'targeting' them (that is to say 
> ignoring non-C-style languages).
>

I already knew about this at some level, but it was quite interesting
actually seeing it happen on the technical forums/discussion groups
over the last few days.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world