in reply to Projects where people can die

I would not use Perl. Nor any language that cannot be compiled to machine code and run from ROM. Harddisks can suffer dropouts.

In at least one machine code, a one-bit change in an opcode could change a common condition JUMP instruction in to a HALT instruction.

A single bit change in a ascii '0' makes it an ascii '1' and vice vera. In Perl, that could make 

while( 1 ) {
   ## Critical code
}

[download]

Into 

while( 0 ) {
    ## Critical code that never gets run.
}

[download]

With compiled code written to ROM (PROM, EEPROM maybe), preferably with EEC and an embedded crc check, testing can validate the final binary image. There are simply too many possibilities of accidental or malicious change to the source code of non-compiled, and runtime compiled languages.

I'd use Perl to prototype it maybe, and to test it, but not for final, life-critical application code.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Projects where people can die
by davis (Vicar) on Sep 07, 2006 at 22:27 UTC
    A single bit change in a ascii '0' makes it an ascii '1' and vice vera.

    Well, yes, it does. However this could equally happen at runtime after the code's loaded from ((EE)?P)?ROM — are you going to guarantee the absence of the effects of cosmic rays / radiation / jam on your processor? This makes the programming language you've used irrelevant.

    The safer way to provide security is to have multiple redundant, different (many people miss this distinction) systems checking each others' results. NASA (IIRC) use three machines to perform the same navigation/guidance tasks — if one disagrees, it's deactivated. They also have a "just land this thing" computer system which can be brought up manually.1.

    Have multiple systems, written by different people, presumably in different languages, cross-checking their results. When they have different results, you have a problem — a bit like realtime testing, if you will.

    1: I don't know if the separate computers are different... and I'm not sure of the exact numbers.

    Update: I've now re-read some of the posts further down about validating the correctness of the OS/compiler etc.... I wouldn't use Perl either. I would, however, still advocate different systems cross-checking their results.


    davis
    Kids, you tried your hardest, and you failed miserably. The lesson is: Never try.
[reply]
      Are you going to guarantee the absence of the effects of cosmic rays / radiation / jam on your processor?

      Well, there are such things as space-rated cpus, and in any environment/application where radiation is a hazard, they would be used along with secondary protection (lead or gold shielding)--but hardware has moving parts; is subject to wear and tear and tolorances. Hardware fails. Disks fail. Even high quality brand new disks fail. Of course, you can run extensive tests to reduce the likelyhood of some failure modes, but in doing so you run the risk of increasing the likelyhood of others--through wear and tear.

      In anycase, there are no guarentees.

      • Maybe the computer will be hit by a crashing airliner, so you bury it underground encased in steel and concrete.
      • But then you might have an earthquake that vibrates something loose--so you suspend the computer inside its concrete coffin to isolate it from that.
      • But the power supply might get severed--so you put a generator inside the coffin.
      • But that might fail--so you add two.

      It's all about likelyhood, and the most vulnerable component in most computer systems is the harddisk. That's why solid state secondary storage is such a holy grail. Removing that from the equation just makes sense.

      With no guarentees, it's all about minimising risk. And that's about spending your money to achieve the biggest bang for you buck. Of the millions of computer users around the world, it's probable that 5 or 10% have experienced some form of disk failure. I have.

      How many have experienced cpu failure--of any kind? Of those that have, how many could be attributed to some form of radiation degeneration of the cpu (or memory)? Much harder to access as without extreme analysis, there is simply no way to know.

      The point is that it is possible to test Perl code as thouroughly as any other code, but the additional step of repetitive runtime compilation is one further possibility of failure, For non-life critical systems, the additional risk is (in most cases), not worth the cost of elimination. But for life-critical systems, it is not worth the risk not to.

      The safer way to provide security is to have multiple redundant, different (many people miss this distinction) systems checking each others' results.

      I'm cognisant of the technique.

      Applied to a Perl program, this would entail producing a completely separate implementation of perl. Since there are no specs--the existing sources are the spec--there is nothing against which to build such a system, let alone verify it.

      I have a memory of reading an artical--possibly related to the fly-by-wire systems on Eurobus aircraft--that suggested that using a single set of sources compiled by different compilers and targetted at different cpus was better than producing two set of sources in different languages. I can't find references. From memory, the rational went that by starting with a single set of sources, it reduced the complexity, by removing the need to try and prove that two language implementations were equivalent. That somewhat unintuative conclusion actually makes economic sense. Every reduction in complexity comes with an increase in the possibility of proof. Maybe :)

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        How many have experienced cpu failure--of any kind? Of those that have, how many could be attributed to some form of radiation degeneration of the cpu (or memory)? Much harder to access as without extreme analysis, there is simply no way to know.

        I have experienced failure which, after extreme analysis, we could only attribute to radiation degeneration of a byte of memory - see Re: What do you know, and how do you know that you know it? for some details.

        Later in the same job I was writing interrupt handlers for a new ARM-based chipset, and found a problem in that chipset - a bug in certain (characterisable) situations when a multiple-register store instruction crossed a 64k page boundary. Somehow that did less to shake my confidence in the perfection of hardware than the memory corruption problem.

        Hugo

[reply]
      ... are you going to guarantee the absence of the effects of cosmic rays / radiation / jam on your processor?

      Actually (BEGIN ANECDOTAL EVIDENCE . . .) I had a software engineering prof in college that used to work on military spec systems. She told a story of doing a demo for some Air Force brass of some sort of avionics that was supposed to be able to work after taking fire. Right before the demo, one of the officers came up and popped out a chip from the board.

      She said it still passed . . . :)

      So yeah, there are people who engineer things for those type of environments with those kind of constraints.

[reply]

In Section Meditations