Tod durch Softwarefehler

[Frank Buss]

Durch fehlerhafte Software in der Firmware von Toyota ist mindestens
eine Person gestorben:

http://www.eetimes.com/document.asp?doc_id=1319903
(Cookies ausschalten, wenn man alle drei Seiten ohne Anmeldung lesen will)

Ich habe zwar nicht den 800-Seiten Bericht gelesen (falls der überhaupt
öffentlich zugänglich ist), aber der Titel des Artikels ist etwas
missverständlich, da ich es für unwahrscheinlich halte, daß der Unfall
durch einen Bit-Flip zustande kam, sondern eher weil in der Software
tatsächlich Stack Overflow und Race-Condition Fehler waren.

Wie kann man Stack Overflow Fehler bei so kritische Software übersehen?
In jeder besseren IDE, z.B. die CodeWarrior Reihe, bekommt man eine
automatisch generierte Analyse des Call-Trees angezeigt, mit Ausnutzung
des Stacks (kann der GCC glaube ich auch mit Zusatzprogrammen, die die
Intermediate-XML-Dateien auswerten). Auch wenn da viele Threads parallel
liefen, war deren Anzahl endlich und wahrscheinlich auch nur einmal beim
Programmstart gestartet, sodaß man jeden Thread einfach addieren könnte.

Race-Conditions sind natürlich schwieriger zu finden, aber durch
sorgfältige Programmierung und Analyse der Locks auch vermeidbar.

Eine andere Frage: wie kann man ein Programm gegen Bit-Flips absichern?
Man müsste ja alle möglichen Auswirkungen von Bit-Flips (auch im Flash)
untersuchen. Und was macht man, wenn man ein Bit-Flip detektiert? Auf
der Autobahn eine Vollbremsung einleiten wäre wohl nicht so gut.

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

 

[Gerrit Heitsch]

On 10/28/2013 04:50 PM, Frank Buss wrote:

Eine andere Frage: wie kann man ein Programm gegen Bit-Flips absichern?

RAM mit ECC verwenden? Die Erkennung passiert in Hardware, ebenso die
Korrektur von Einzelbitfehlern.

Problem ist eher, daß die meisten Controller das nicht können weils eben
billig sein muss.

Man müsste ja alle möglichen Auswirkungen von Bit-Flips (auch im Flash)
untersuchen. Und was macht man, wenn man ein Bit-Flip detektiert? Auf
der Autobahn eine Vollbremsung einleiten wäre wohl nicht so gut.

Single-Bit-Fehler sind bei Verwendung von ECC-RAM problemlos
korrigierbar. Kippen zwei Bits in einem Wort geht das nicht mehr so
einfach, aber wenn es wirklich kritisch ist, dann muss man eben den
Aufwand treiben...

Gerrit

 

[Frank Buss]

Gerrit Heitsch wrote:

Single-Bit-Fehler sind bei Verwendung von ECC-RAM problemlos
korrigierbar. Kippen zwei Bits in einem Wort geht das nicht mehr so
einfach, aber wenn es wirklich kritisch ist, dann muss man eben den
Aufwand treiben...

Stimmt, ECC-RAM wäre eine gute Idee, dann kann man sogar Mehrbitfehler
detektieren. Bleibt dann aber noch die Frage, was die Software machen
soll, wenn so ein Fehler erkannt wurde.

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

 

[Marc Santhoff]

Frank Buss <fb@frank-buss.de> schrieb:

Gerrit Heitsch wrote:

Single-Bit-Fehler sind bei Verwendung von ECC-RAM problemlos
korrigierbar. Kippen zwei Bits in einem Wort geht das nicht mehr so
einfach, aber wenn es wirklich kritisch ist, dann muss man eben den
Aufwand treiben...

Stimmt, ECC-RAM wäre eine gute Idee, dann kann man sogar Mehrbitfehler
detektieren. Bleibt dann aber noch die Frage, was die Software machen
soll, wenn so ein Fehler erkannt wurde.

Stand doch in dem Artikel sogar drin: kritische Variablen mehrfach
spiegeln. Und natürlich beim Lesezugriff vergleichen.

Marc

 

[Gerrit Heitsch]

On 10/28/2013 05:03 PM, Frank Buss wrote:

Gerrit Heitsch wrote:

Single-Bit-Fehler sind bei Verwendung von ECC-RAM problemlos
korrigierbar. Kippen zwei Bits in einem Wort geht das nicht mehr so
einfach, aber wenn es wirklich kritisch ist, dann muss man eben den
Aufwand treiben...

Stimmt, ECC-RAM wäre eine gute Idee, dann kann man sogar Mehrbitfehler
detektieren. Bleibt dann aber noch die Frage, was die Software machen
soll, wenn so ein Fehler erkannt wurde.

Notprogramm starten. Hat jedes Auto schon jetzt und erlaubt auch noch
das Fahren, aber mit stark reduzierter Leistung und ohne die meisten
Features wie ABS, ESP... Sowas kann man vom Code her ziemlich klein halten.

Beispiel war ein Klemmer im verstellbaren Turbolader meines letzten
Autos. Damit wird der Ladedruck zu hoch. Das Steuergerät schaltet dann
alles auf Minimum. Du meinst dann es wurde der halbe Motor ausgebaut so
mies fährt sich die Kiste.

Gerrit

 

[Joerg]

Marc Santhoff wrote:

Frank Buss <fb@frank-buss.de> schrieb:

Gerrit Heitsch wrote:

Single-Bit-Fehler sind bei Verwendung von ECC-RAM problemlos
korrigierbar. Kippen zwei Bits in einem Wort geht das nicht mehr so
einfach, aber wenn es wirklich kritisch ist, dann muss man eben den
Aufwand treiben...
Stimmt, ECC-RAM wäre eine gute Idee, dann kann man sogar Mehrbitfehler
detektieren. Bleibt dann aber noch die Frage, was die Software machen
soll, wenn so ein Fehler erkannt wurde.

Stand doch in dem Artikel sogar drin: kritische Variablen mehrfach
spiegeln. Und natürlich beim Lesezugriff vergleichen.

Man muss lediglich bei den Flugzeugbauern nachsehen. Viele kritische
Systeme muessen redundant vorhanden sein, z.B. dreifach mit
Mehrheitsentscheidung. Patzt einer der Computer, muss gemeldet und
gelandet werden. Ganz heisse Sachen sind fuenffach vorhanden, weil man
auf Reiseflughoehe schlecht anhalten und auf den ADAC Abschleppdienst
warten kann. Hier einige Grundzuege am Beispiel Airbus:

http://exoaviation.webs.com/pdf_files/Airbus%20flight%20control%20system.pdf

Zitat "Therefore, quintuple redundancy is supported".

Was Software angeht, z.B. den Standard RTCA/DO-178 besorgen und danach
arbeiten. Ich lebe fast nach solchen Standards, man gewoehnt sich dran.
Doch es gibt im Bereich KFZ-Elektronik (m.W.) nichts vergleichbares,
ausser Vorschriften einzelner Hersteller.

Ich hege wenig Hoffnung, dasss sich im Bereich Automotive in dieser
Hinsicht viel bessert. Ergo bevorzuge ich Vehikel mit sowenig Elektronik
wie moeglich.

--
Gruesse, Joerg

http://www.analogconsultants.com/

 

[Marc Santhoff]

Joerg <invalid@invalid.invalid> schrieb:

Was Software angeht, z.B. den Standard RTCA/DO-178 besorgen und danach
arbeiten. Ich lebe fast nach solchen Standards, man gewoehnt sich
dran. Doch es gibt im Bereich KFZ-Elektronik (m.W.) nichts
vergleichbares, ausser Vorschriften einzelner Hersteller.

Ich hege wenig Hoffnung, dasss sich im Bereich Automotive in dieser
Hinsicht viel bessert. Ergo bevorzuge ich Vehikel mit sowenig
Elektronik wie moeglich.

https://de.wikipedia.org/wiki/MISRA-C

Marc

 

[Frank Buss]

Marc Santhoff wrote:

Stand doch in dem Artikel sogar drin: kritische Variablen mehrfach
spiegeln. Und natürlich beim Lesezugriff vergleichen.

Ja, das hatte ich auch gelesen und würde wohl die Wahrscheinlichkeit von
einzelne Bitfehlern im RAM reduzieren, wenn der Programmierer alle
kritischen Stellen beachtet und wenn man Glück hat und der Bitfehler
nicht im Stack auftritt, oder im Flash im Programmcode.

Ich denke das beste wäre wohl, wenn sowohl Flash, als auch RAM per ECC
abgesichtert wäre und beim einem Fehler dort dann von der Hardware per
Exception eine Notfallroutine aufgerufen wird, ggf. in einem extra
gesicherten Flash. Oder redundant aufbauen, mit Hardware
Mehrheitsentscheidung, wie Jörg schrieb. Bei einem Auto für 10k Euro
sollte doch eigentlich eine dreifache Ausführung eines 3 Euro
Microcontrollers, und 2 Euro für ein kleines CPLD, kein Problem sein.

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

 

[Joerg]

Marc Santhoff wrote:

Joerg <invalid@invalid.invalid> schrieb:

Was Software angeht, z.B. den Standard RTCA/DO-178 besorgen und danach
arbeiten. Ich lebe fast nach solchen Standards, man gewoehnt sich
dran. Doch es gibt im Bereich KFZ-Elektronik (m.W.) nichts
vergleichbares, ausser Vorschriften einzelner Hersteller.

Ich hege wenig Hoffnung, dasss sich im Bereich Automotive in dieser
Hinsicht viel bessert. Ergo bevorzuge ich Vehikel mit sowenig
Elektronik wie moeglich.

https://de.wikipedia.org/wiki/MISRA-C

http://www.dspace.de/ftp/papers/dspace_El25_0312_d_f28.pdf

Zitat "Damit ist die Zielgruppe, auf welche sich der Standard bezieht,
recht klar definiert: der Mensch als Software-Entwickler"

Das ist wohl ziemlich daneben. Es kommt nicht ein einziges Mal das Wort
"Ausfall" vor. Klar ist der Mensch ein haeufiger Verursacher, aber ein
Standard fuer Computerei in Verkehrsmitteln muss auch den Ausfall von
Hardware sowie Unfaelle beruecksichtigen. Bei meinen Projekten z.B.
schonmal das Verhalten bei und nach nicht ganz knitterfreien Landungen.

--
Gruesse, Joerg

http://www.analogconsultants.com/

 

[Eric Brücklmeier]

Am 28.10.2013 16:50, schrieb Frank Buss:

Durch fehlerhafte Software in der Firmware von Toyota ist mindestens
eine Person gestorben:

http://www.eetimes.com/document.asp?doc_id=1319903
(Cookies ausschalten, wenn man alle drei Seiten ohne Anmeldung lesen will)

Ich habe zwar nicht den 800-Seiten Bericht gelesen (falls der überhaupt
öffentlich zugänglich ist), aber der Titel des Artikels ist etwas
missverständlich, da ich es für unwahrscheinlich halte, daß der Unfall
durch einen Bit-Flip zustande kam, sondern eher weil in der Software
tatsächlich Stack Overflow und Race-Condition Fehler waren.

Wie kann man Stack Overflow Fehler bei so kritische Software übersehen?

Och, such mal nach Softwarefehler Ariane 5 oder Patriot System...

 

[Gerrit Heitsch]

On 10/28/2013 05:44 PM, Joerg wrote:

Das ist wohl ziemlich daneben. Es kommt nicht ein einziges Mal das Wort
"Ausfall" vor. Klar ist der Mensch ein haeufiger Verursacher, aber ein
Standard fuer Computerei in Verkehrsmitteln muss auch den Ausfall von
Hardware sowie Unfaelle beruecksichtigen. Bei meinen Projekten z.B.
schonmal das Verhalten bei und nach nicht ganz knitterfreien Landungen.

Any landing you can walk away from is a good one!

Gerrit

 

[Joerg]

Gerrit Heitsch wrote:

On 10/28/2013 05:44 PM, Joerg wrote:

Das ist wohl ziemlich daneben. Es kommt nicht ein einziges Mal das Wort
"Ausfall" vor. Klar ist der Mensch ein haeufiger Verursacher, aber ein
Standard fuer Computerei in Verkehrsmitteln muss auch den Ausfall von
Hardware sowie Unfaelle beruecksichtigen. Bei meinen Projekten z.B.
schonmal das Verhalten bei und nach nicht ganz knitterfreien Landungen.

Any landing you can walk away from is a good one!

Aber nur bis der Schadensregulierer von der Versicherung kommt, und die
Leute von der Flugaufsichtsbehoerde, und Cheffe einen Tobsuchtsanfall
bekommt. Wie war das bei Heinz Ruehmann? "Och, nu ja, die Landung hat
geklappt. Nur beim Motor, da ist, aehm, ja, also, da is'n Stueck
abgebrochen. Und am Propeller auch. Und ... ".

--
Gruesse, Joerg

http://www.analogconsultants.com/

 

[Joerg]

Frank Buss wrote:

Marc Santhoff wrote:
Stand doch in dem Artikel sogar drin: kritische Variablen mehrfach
spiegeln. Und natürlich beim Lesezugriff vergleichen.

Ja, das hatte ich auch gelesen und würde wohl die Wahrscheinlichkeit von
einzelne Bitfehlern im RAM reduzieren, wenn der Programmierer alle
kritischen Stellen beachtet und wenn man Glück hat und der Bitfehler
nicht im Stack auftritt, oder im Flash im Programmcode.

Ich denke das beste wäre wohl, wenn sowohl Flash, als auch RAM per ECC
abgesichtert wäre und beim einem Fehler dort dann von der Hardware per
Exception eine Notfallroutine aufgerufen wird, ggf. in einem extra
gesicherten Flash. Oder redundant aufbauen, mit Hardware
Mehrheitsentscheidung, wie Jörg schrieb. Bei einem Auto für 10k Euro
sollte doch eigentlich eine dreifache Ausführung eines 3 Euro
Microcontrollers, und 2 Euro für ein kleines CPLD, kein Problem sein.

Exakt da liegt das Problem. Bei einem 10k Auto wird selbst mit 10 Cents
geknausert. Einige Euros mehr sind selbst bei einer Luxuskarosse
undenkbar. Das schlimmere ist jedoch, dass sie auch bei den NRE knausern
und deshalb sowie wegen zu eng gesetzter Arbeitsplaene und Messetermine
Entwicklungen freigeben, die noch gar nicht richtig ausgegoren sind.

--
Gruesse, Joerg

http://www.analogconsultants.com/

 

[Heiko Nocon]

Frank Buss wrote:

>Eine andere Frage: wie kann man ein Programm gegen Bit-Flips absichern?

Nicht wirklich.

Man müsste ja alle möglichen Auswirkungen von Bit-Flips (auch im Flash)
untersuchen.

Als erstes mußt du sie erstmal zuverlässig erkennen. OK, Ein-Bit-Fehler
sind leicht zu erkennen. Aber was, wenn nun ausgerechnet in der
Parity-Einheit ein Bit kippt?

Hier deutet sich schon im Kleinen an, was auch für große Systeme gilt.

>Und was macht man, wenn man ein Bit-Flip detektiert?

Das ist das eigentliche Problem. Save recovery aus jeder denkbaren
Situation potenziert die Komplexität der Software und damit wiederum die
Zahl der denkbaren Situationen. Eine nette unendliche exponentielle
Rekursion.

Der einzige realistische Ausweg ist deswegen die Vollbremsung mit
automatischem Neustart.

 

[Gerrit Heitsch]

On 10/28/2013 06:03 PM, Heiko Nocon wrote:

Frank Buss wrote:

Eine andere Frage: wie kann man ein Programm gegen Bit-Flips absichern?

Nicht wirklich.

Man müsste ja alle möglichen Auswirkungen von Bit-Flips (auch im Flash)
untersuchen.

Als erstes mußt du sie erstmal zuverlässig erkennen. OK, Ein-Bit-Fehler
sind leicht zu erkennen. Aber was, wenn nun ausgerechnet in der
Parity-Einheit ein Bit kippt?

Dann wird ein Fehler erkannt, der keiner ist. Besser als einen Fehler
übersehen.

Ansonsten ist ECC-RAM bei Servern Standard und sollte es eigentlich auch
bei PCs sein. Wer schon einmal Stunden mit einem instabilen System
verbracht hat (memtest86+ findet nicht alles), der zahlt die paar Euro
extra für ECC-RAM mit Freuden.

Und was macht man, wenn man ein Bit-Flip detektiert?

Das ist das eigentliche Problem. Save recovery aus jeder denkbaren
Situation potenziert die Komplexität der Software und damit wiederum die
Zahl der denkbaren Situationen. Eine nette unendliche exponentielle
Rekursion.

Der einzige realistische Ausweg ist deswegen die Vollbremsung mit
automatischem Neustart.

Nein, das Laden eines Notprogrammes welches möglichst wenige Resourcen
benutzt und das System möglichst schonend in einen sicheren Zustand
(beim Auto: angehalten, Motor aus, in dieser Reihenfolge) überführt ohne
dabei den Fahrer oder andere Verkehrsteilnehmer zu gefährden. Damit
fällt die Vollbremsung schonmal aus.

Gerrit

 

[Bernd Laengerich]

Am 28.10.2013 17:49, schrieb Gerrit Heitsch:

> Any landing you can walk away from is a good one!

Eine gute Landung ist eine, bei der das Flugzeug in einem Stück bleibt.
Eine hervorragende Landung ist eine, nach der das Flugzeug noch einmal
verwendet werden kann.

Bernd
--
Meine Glaskugel ist mir leider unvorhersehbarerweise vom Balkon gefallen.
P.Liedermann in defa

 

[Gerrit Heitsch]

On 10/28/2013 06:24 PM, Bernd Laengerich wrote:

Am 28.10.2013 17:49, schrieb Gerrit Heitsch:

Any landing you can walk away from is a good one!

Eine gute Landung ist eine, bei der das Flugzeug in einem Stück bleibt.
Eine hervorragende Landung ist eine, nach der das Flugzeug noch einmal
verwendet werden kann.

Was ist dann eine Landung nach der das Flugzeug direkt aus eigener Kraft
wieder starten kann?

Gerrit

 

[Bernd Laengerich]

Am 28.10.2013 18:26, schrieb Gerrit Heitsch:

Was ist dann eine Landung nach der das Flugzeug direkt aus eigener Kraft
wieder starten kann?

Ist solch ein Vorkommen überliefert? Fällt ansonsten unter den zweiten Punkt

Bernd
--
Meine Glaskugel ist mir leider unvorhersehbarerweise vom Balkon gefallen.
P.Liedermann in defa

 

[Gerrit Heitsch]

On 10/28/2013 06:46 PM, Bernd Laengerich wrote:

Am 28.10.2013 18:26, schrieb Gerrit Heitsch:

Was ist dann eine Landung nach der das Flugzeug direkt aus eigener Kraft
wieder starten kann?

Ist solch ein Vorkommen überliefert?

Ja, hier schon selbst gesehen:

http://de.wikipedia.org/wiki/Nationalpark_Canaima

Landebahn mitten im Dschungel, rundrum nur Wald. Dort mit einer 727
(kurze Version) gelandet, ausgestiegen und die gleich wieder weiter,
ohne auftanken (wie auch?).


Gerrit

 

[Eric Brücklmeier]

Am 28.10.2013 18:55, schrieb Gerrit Heitsch:

On 10/28/2013 06:46 PM, Bernd Laengerich wrote:
Am 28.10.2013 18:26, schrieb Gerrit Heitsch:

Was ist dann eine Landung nach der das Flugzeug direkt aus eigener Kraft
wieder starten kann?

Ist solch ein Vorkommen überliefert?

Ja, hier schon selbst gesehen:

http://de.wikipedia.org/wiki/Nationalpark_Canaima

Landebahn mitten im Dschungel, rundrum nur Wald. Dort mit einer 727
(kurze Version) gelandet, ausgestiegen und die gleich wieder weiter,
ohne auftanken (wie auch?).

Auch hier muß es klappen:

http://www.white-desert.com/wp-content/uploads/2012/06/8-Novo-runway-and-surrounding-buildings2.jpg

sogar mit sehr fettem Gerät (IL-76) - allerdings mit Auftanken...