[pro] Heartbleed?

Mon Apr 28 14:09:21 UTC 2014

Regarding the question

What would you personally fly, software written in C or software written in
Common Lisp?

In the reality of today's fly-by-wire, the modern planes you fly in are
likely to have C in some critical component. Ada is likely there as well.

But let's just examine a few software related disasters to see if they are
attributable to programming language:

   - Ariane 5 rocket explosion: from the official report: This loss of
   information was due to specification and design errors in the software of
   the inertial reference system.
   - Mars Climate Orbiter: one system used metric units, another used
   English
   - Therac 5: improper understanding of multi-tasking code
   - Heartbleed: Overly complex protocol combined with being able to read
   beyond allocated memory

Of these, only heartbleed can credit language as a contributing factor.

And I again point out a software non-disaster qmail, whose author offered a
bug bounty. Secure programs can be written in C.

And if the flight safety of an aircraft depended upon the current Lisp
version of Ironclad's impenetrability, we would be in trouble.

I do prefer Lisp, and as I have said before, I think it is easier to write
correct and thus secure and safe programs in Lisp, but that is only a small
part of the story. Other critical parts to the story are:

   - How well is the software specified?
   - Who is the team writing the software? Are they CMM level 5?
   - Is the software tuned to the user situation at hand? When the engine
   exploded on the Quantas flight 32, the pilots had to deal with an almost
   overwhelming number of alerts.

You do ask a good question, but in my opinion, choice of language is not at
the top of the list.

wglb
(P. S. I am not a lisp expert, but I have been programming for 48 years,
including real-time medical software, compilers, financial feed software.
 For the medical system, we used assembly language. C had not yet been
invented, but turns out that doing coroutines in assembler was better than
threads showing up later in C.)

On Sun, Apr 27, 2014 at 10:31 PM, Jean-Claude Beaudoin <
jean.claude.beaudoin at gmail.com> wrote:

>
>
>
> On Sun, Apr 27, 2014 at 4:27 AM, Steve Haflich <shaflich at gmail.com> wrote:
>
>> I agree with essentially everything in wglb's message, but (once again)
>> I'll grumpily jump in to emphasize a point which I think many on this list
>> have missed.
>>
>>
>> On Fri, Apr 25, 2014 at 1:20 PM, William Lederer <
>> william.lederer at gmail.com> wrote:
>>
>>>
>>> I agree with the general sentiment that Lisp is a much safer language to
>>> build anything in. While several in this thread are pointing to bounds
>>> checking as one of the advantages that Lisp has over C and other languages,
>>> there is something else I find that is also very strong: It is easier to
>>> write programs about which a reader can reason about correctness. In Lisp,
>>> the programs tend to be closer to provable and errors are more evident. As
>>> in "obviously no deficiencies" vs "no obvious deficiencies".
>>>
>>> But in my experience, vulnerabilities result from
>>>
>>>    - Buffer Overflows/lack of bounds checking (Heartbleed and friends)
>>>    - Configuration errors
>>>    - Logic Flaws
>>>    - Dangerous use of user input (leading to SQLi, XSS, XSRF)
>>>    - Improper use of cryptography
>>>    - Unclear protocol specification (leading to OpenSSL)
>>>
>>> This (IMO entirely worthy and correct) summary can easily be
>> misunderstood!  Lisp may be superior because it has bounds checking. (We've
>> previously agreed that isn't guaranteed since it isn't in the ANS, and in
>> any platform likely depends on optimization qualities, including the
>> optimization qualities under which internal called routines were compiled.)
>>  But bugs based on buffer overflow don't on normal operating systems in
>> general involve bounds checking.  At some point on any modern OS, reading
>> or writing to a socket stream will involve passing to the OS (generally via
>> a thin user-mode C API layer like *nix read() and write(), or some socket
>> analogue).  Neither Lisp nor C will provide any automatic bounds checking
>> on such a call.  The OS treats the application's address space as a
>> mostly-contiguous undifferentiated sea of bytes(*).  It doesn't matter that
>> at the app level C also has this model of a sea of bytes, while in Lisp the
>> ocean is run-time tagged into small plots.  That distinction disappears
>> once one calls write(fd,buf,len).
>>
>> The Lisp Machine in its several manifestations might be the only
>> counterexample, since there was no C boundary over which to cross, and
>> because type and bounds checking was performed for free in the microcode.
>>  But Lisp machines aren't around any more largely because of the economy of
>> scale.  The number of x86 and x64 processors on the planet must be nearly
>> on the order of 10^9, while the number of Lisp machine processors never got
>> out of the 10^5 range, so Intel and AMD etc. could justify huge investments
>> making those processors 3 orders of magnitude faster in raw speed.  Lisp
>> processors could not have kept up at bearable per-item cost.  Alas!
>>
>>
> I think it is not only a question of level of investment or either a
> question of Lisp in hardware or an other higher language in hardware for
> that matter. There seems to be some physico-technical optimality point in
> question here at the hardware/software interface.  From my (fading?)
> memories of a past era I can somewhat recall that the last (I think) major
> CPU architecture that took security support seriously in hardware was the
> Intel iAPX 432, with multiple nested security rings in hardware/descriptor
> supported gates/instructions. (BTW, the 432 was meant to support Ada of all
> languages, not C or Lisp, but it was general-purpose enough).  And history
> has recorded how well this iAPX 432 architecture flew.
>
> And while I am using the word "fly" I have that urge to ask you guys that
> question: What would you personally fly, software written in C or software
> written in Common Lisp?  And I mean it quite literally, with you sitting in
> the plane.  I think that the fact that one can seriously ask that question
> is one of the most significant evolution in the demands the general context
> presents to any programming language standard. In 1994 fly-by-wire was
> cutting edge and still quite experimental, now in 2014 it is the reality of
> every day on routine commercial flight.
>
> I see (a somewhat revised?) Common Lisp as a very good starting point to
> address this new reality.
> Better than C, that is for sure. (How can you even hope to make C more
> safe and secure and yet still
> be C is beyond my understanding, FWIW).
>
>
>
>
> _______________________________________________
> pro mailing list
> pro at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/pro
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20140428/0bada7a6/attachment.html>