Tod durch Softwarefehler

[Gerrit Heitsch]

On 10/29/2013 01:05 AM, Hanno Foest wrote:

Die Komplexität ist heute schon um ein Irrsinniges zu hoch. Wer auf
sowas Beklopptes kommt, wie JavaScript in PDF einzubauen, oder überhaupt
JavaScript - Daten mit Code vermischen, der dann lokal ohne Rückfrage
bei dir ausgeführt wird - der muß sich nicht wundern. Daß JS ein Rezept
für Desaster ist war mir klar, als ich das erste Mal davon gehört habe.

Ja, wie damals als MS ActiveX brachte... Was kann schon schiefgehen wenn
eine Website bei dir x86 Code ausführen darf?

Daten und Code sollte man getrennt halten. Aber auch das ist nicht mehr
machbar, weil sich sonst die ganzen Anwender von Office lautstark
beschweren, daß ihre ganzen Macros nicht mehr funktionieren.

Außerdem müßte man an einem System mit einem Grundstock verifizierten
Codes nicht alle naselang rumpatchen - was ja auch ein potentielles
Einfallstor von Schadsoft ist.

Problem ist dann ein anderes. Wenn es jemand doch schafft ein neues
Einfallstor zu finden weil nie jemand diesen neuen Weg auch nur
angedacht hat, dann wirst du in dasselbe Problem reinlaufen wie damals
bei den PINs der EC-Karten.

"Laut unseren Unterlagen benutzen sie 'Total-sicher-OS'(TM), also muss
der Fehler bei ihnen liegen, wir lehnen jegliche Haftung ab"

Gerrit

 

[Uwe Hercksen]

Joerg schrieb:

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:

Hallo,

zum nächsten erreichbaren Flughafen muss man aber erstmal kommen, auch
wenn man dazu noch den halben Atlantik oder Pazifik überqueren muss.

Bye

 

[Edzard Egberts]

Lutz Schulze schrieb:

Am Tue, 29 Oct 2013 08:09:26 +0100 schrieb Edzard Egberts:

Beim GCC hatte ich Fall, dass die Optimierung das Programm zermurkst
hat.

Was ist da konkret passiert? Bei mir stellten sich in Betracht gezogene
'Compilerfehler' nach genauerer Untersuchung eigentlich immer wieder als
eigene Denkfehler heraus.

Mit PC ein Programm für ein Linux-Board compiliert - lief auf dem PC,
aber nicht auf dem Board. Weniger optimiert lief es dann auch auf dem
Board. Woran genau das lag, habe ich dann nicht untersucht -
Betriebssystem und Software auf PC und Board gleich, könnte eine
Prozessor-Optimierung gewesen sein.

>> Von den drei Optimierungsstufen "more, most, size"

Da habe ich eine übersehen, es sind "none, optimize, more, most, size"
(00, 01, 02, etc.) und empfohlen ist "more" (02).

 

[Hanno Foest]

Am 29.10.2013 08:30 schrieb Gerrit Heitsch:

Ja, die CPU selbst spielt da auch noch rein. Wer erinnert sich noch an
den POPAD-Bug im 386? Korrektes Programm (laut Spec), trotzdem
Datenmüll.

Du brauchst auch entsprechende spezielle (verifizierte) Hardware...

Das ist leider nicht zu 100% machbar. Wie POPAD zeigt müsstest du jede
mögliche Befehlskombination testen.

Wenn du die Hardare auf Verifizierbakeit hin designst hast du bessere
Karten.

Nachdem eine CPU Hardware ist, müsstest du diese Verifikation bei jeder
produzierten CPU machen. Könnte schliesslich ein kleiner Fehler in der
Maske sein der einen Bug einbaut der nicht immer auftritt sondern nur
wenn bestimmte Dinge bei der Produktion (Dotierung, Position auf dem
Wafer) und später im Betrieb zusammenkommen.

Der ist dann aber nicht gezielt exploitbar, weil man sich nicht drauf
verlassen kann.

Hanno

 

[Hanno Foest]

Am 29.10.2013 08:45 schrieb Gerrit Heitsch:

Außerdem müßte man an einem System mit einem Grundstock verifizierten
Codes nicht alle naselang rumpatchen - was ja auch ein potentielles
Einfallstor von Schadsoft ist.

Problem ist dann ein anderes. Wenn es jemand doch schafft ein neues
Einfallstor zu finden weil nie jemand diesen neuen Weg auch nur
angedacht hat, dann wirst du in dasselbe Problem reinlaufen wie damals
bei den PINs der EC-Karten.

"Laut unseren Unterlagen benutzen sie 'Total-sicher-OS'(TM), also muss
der Fehler bei ihnen liegen, wir lehnen jegliche Haftung ab"

Das ist ein soziales Problem, das man nicht mit technischen Mitteln
angehen kann. Wie dein Beispiel zeigt, gibt es das Problem bereits bei
"normal unsicheren" Systemen. Ich seh jetzt aber gar nicht ein, mit
weniger Sicherheit als möglich zu arbeiten, nur weil mir irgendein
Spinner einen Strick draus drehen könnte.

Hanno

 

[Martin Schoenbeck]

Hallo Edzard,

Edzard Egberts schrieb:

Lutz Schulze schrieb:
Am Tue, 29 Oct 2013 08:09:26 +0100 schrieb Edzard Egberts:

Beim GCC hatte ich Fall, dass die Optimierung das Programm zermurkst
hat.

Was ist da konkret passiert? Bei mir stellten sich in Betracht gezogene
'Compilerfehler' nach genauerer Untersuchung eigentlich immer wieder als
eigene Denkfehler heraus.

Mit PC ein Programm für ein Linux-Board compiliert - lief auf dem PC,
aber nicht auf dem Board. Weniger optimiert lief es dann auch auf dem
Board. Woran genau das lag, habe ich dann nicht untersucht -
Betriebssystem und Software auf PC und Board gleich, könnte eine
Prozessor-Optimierung gewesen sein.

Das muß deshalb noch kein Compilerfehler gewesen sein. Womöglich hast Du
eine Optimierung eingeschaltet, die in bestimmten Situationen bzw.
bestimmte Variablen zusätzliche Definitionen erfordert. Wenn die dann
fehlen, kommen da durchaus üble Ergebnisse raus, ohne daß der Compiler
gepfuscht hat.

Gruß Martin
--
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.

 

[Bernd Laengerich]

Am 29.10.2013 08:30, schrieb Gerrit Heitsch:

Nachdem eine CPU Hardware ist, müsstest du diese Verifikation bei jeder
produzierten CPU machen. Könnte schliesslich ein kleiner Fehler in der Maske

Ausserdem kann die CPU später kaputt gehen, da treten ggf. die unmöglichsten
Effekte auf die die Software wieder abschiesst.

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

 

[Ralph A. Schmid, dk5ras]

Joerg <invalid@invalid.invalid> wrote:

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.

Ein Bekannter hatte mal mit Steuergeräteentwicklung zu tun, so als
Projektmanager, der daherkommt, wenn die Kacke am Dampfen ist.

Er wußte durchaus von Begebenheitenm zu berichten, die bedenklich
stimmen. Zwei Teams hocken auf dem selben Flur, entwickeln jeweils ein
Steuergerät, sehen sich täglich auf dem Flur und in der Kantine, und
paar Tage vor Projektende werden die zwei Geräte erstmalig verbunden -
nichts funktioniert. Hat eines der Teams die specs der Telegramme
anders aufgefaßt als das andere Team, großer Streit, großes Chaos,
Kunde not amused, mein Bekannter muß mit ran und vermittelnd wirken,
man raucht die Friedenspfeife, strickt wild in Nachtschichten herum,
und zum Tag x funktiniert der Krempel. Irgendwie halt. Nicht wirklich
geprüft, nicht wirklich erprobt, aber der Kunde ist zufrieden,
Hauptsache, das Zeug läuft, die Dinger kommen in die Prototypen, und
wenig später in Serie. Ohne daß nochmal einer nachgebessert hätte, den
code aufgeräumt und verifiziert - warum auch, läuft ja.

Geht ja offenbar fast immer dennoch irgendwie gut, aber ein Gschmäckle
bleibt da schon, zumal solche Begebenheiten nict die Ausnahme sind.
Und das waren große, bekannte Namen, deutsch und nordeuropäisch...


-ras

--

Ralph A. Schmid

http://www.schmid.xxx/ http://www.db0fue.de/
http://www.bclog.de/ http://www.kabuliyan.de/

 

[Thomas Stanka]

Am Montag, 28. Oktober 2013 17:39:15 UTC+1 schrieb Frank Buss:

Marc Santhoff wrote:

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

Wird man zwar im Regelfall auch bei Flash so machen, aber meines Wissens ist die eigentliche Zelle nach dem Schreiben im Flash relativ sicher gemessen am restlichen System, was üblicherwiese "kippt" sind die Daten ausserhalb der Zelle z.b. beim Auslesen oder im Prozessor-Cache/Registerbank/Pipeline/... oder aber die Daten während des Schreibzugriffs.

 

[Edzard Egberts]

Martin Schoenbeck schrieb:

Edzard Egberts schrieb:
Mit PC ein Programm für ein Linux-Board compiliert - lief auf dem PC,
aber nicht auf dem Board. Weniger optimiert lief es dann auch auf dem
Board. Woran genau das lag, habe ich dann nicht untersucht -
Betriebssystem und Software auf PC und Board gleich, könnte eine
Prozessor-Optimierung gewesen sein.

Das muß deshalb noch kein Compilerfehler gewesen sein. Womöglich hast Du
eine Optimierung eingeschaltet, die in bestimmten Situationen bzw.
bestimmte Variablen zusätzliche Definitionen erfordert. Wenn die dann
fehlen, kommen da durchaus üble Ergebnisse raus, ohne daß der Compiler
gepfuscht hat.

Um mir eine genauere Definitionen des Begriffs "Fehler" zu sparen, nenne
ich das einfach mal "Ereignis". Damals habe ich gelernt, dass solche
Ereignisse durch Optimierungen über Stufe 02 verursacht werden. Seitdem
liefere ich mit Stufe 02 aus, was mir auch als völlig ausreichend
erscheint - Software, die sowieso schon klein und schnell genug ist,
wird damit möglicherweise robuster, was den Betrieb auf
unterschiedlichen Systemen angeht.

Den Link zum Artikel, im dem allgemein empfohlen wird, diese
Optimierungen möglichst zu vermeiden, finde ich aber nicht mehr - wenn
es jemand wirklich noch genauer wissen muss, sollte der nach
de.comp.os.unix.programmer fuppen.

 

[Gerrit Heitsch]

On 10/29/2013 09:50 AM, Hanno Foest wrote:

Am 29.10.2013 08:30 schrieb Gerrit Heitsch:

Ja, die CPU selbst spielt da auch noch rein. Wer erinnert sich noch an
den POPAD-Bug im 386? Korrektes Programm (laut Spec), trotzdem
Datenmüll.

Du brauchst auch entsprechende spezielle (verifizierte) Hardware...

Das ist leider nicht zu 100% machbar. Wie POPAD zeigt müsstest du jede
mögliche Befehlskombination testen.

Wenn du die Hardare auf Verifizierbakeit hin designst hast du bessere
Karten.

Ich nehme mal an, die CPU-Hersteller tun jetzt schon was geht, ganz in
ihrem eigenen Interesse. Ausserdem kenne sie die problematischen Pfade
und passen auf die genau auf. Trotzdem sind heutige CPUs leider nicht
100% verifizierbar und eine neue Architektur dürfte sich nicht
durchsetzen können. x86/x64 funktioniert gut genug.

Gerrit

 

[Joerg]

Uwe Hercksen wrote:

Joerg schrieb:

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:

Hallo,

zum nächsten erreichbaren Flughafen muss man aber erstmal kommen, auch
wenn man dazu noch den halben Atlantik oder Pazifik überqueren muss.

Klar. Bei uns war es ein Triebwerk (von zweien) einer Boeing 767, das
ueber dem Atlantik graetschte. Dann muss das andere bis zum Festland
reichen, und das tat es auch. Selbst wenn die normale Reiseflughoehe
nicht gehalten werden konnte.

--
Gruesse, Joerg

http://www.analogconsultants.com/

 

[Hanno Foest]

Am 29.10.2013 14:27 schrieb Gerrit Heitsch:

Trotzdem sind heutige CPUs leider nicht
100% verifizierbar und eine neue Architektur dürfte sich nicht
durchsetzen können. x86/x64 funktioniert gut genug.

Das ist auch der Grund, warum keine Anstrengungen bzgl. verifizierbarer
Software unternommen werden: Es funktioniert gut genug, und für die
Fälle, wo es das nicht tut, gibt es Versicherungen.

Es funktioniert aber auch schlecht genug, so daß man den Leuten dauernd
was neues verkaufen kann. Und obendrein müßte Software zur automatischen
Verifikation quelloffen sein und das geht ja nun gar nicht.

Ich will mich dennoch nicht solchen Marktzwängen unterwerfen müssen.

Hanno

 

[Joerg]

Ralph A. Schmid, dk5ras wrote:

Joerg <invalid@invalid.invalid> wrote:

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.

Ein Bekannter hatte mal mit Steuergeräteentwicklung zu tun, so als
Projektmanager, der daherkommt, wenn die Kacke am Dampfen ist.

Er wußte durchaus von Begebenheitenm zu berichten, die bedenklich
stimmen. Zwei Teams hocken auf dem selben Flur, entwickeln jeweils ein
Steuergerät, sehen sich täglich auf dem Flur und in der Kantine, und
paar Tage vor Projektende werden die zwei Geräte erstmalig verbunden -
nichts funktioniert. Hat eines der Teams die specs der Telegramme
anders aufgefaßt als das andere Team, großer Streit, großes Chaos,
Kunde not amused, mein Bekannter muß mit ran und vermittelnd wirken,
man raucht die Friedenspfeife, strickt wild in Nachtschichten herum,
und zum Tag x funktiniert der Krempel. Irgendwie halt. Nicht wirklich
geprüft, nicht wirklich erprobt, aber der Kunde ist zufrieden,
Hauptsache, das Zeug läuft, die Dinger kommen in die Prototypen, und
wenig später in Serie. Ohne daß nochmal einer nachgebessert hätte, den
code aufgeräumt und verifiziert - warum auch, läuft ja.

Scheinbar gibt es dort nichtmal in-house Standards fuer Design History
oder Verifizierung. Vermutlich nichtmal richtige Design Reviews. <grusel>

Geht ja offenbar fast immer dennoch irgendwie gut, aber ein Gschmäckle
bleibt da schon, zumal solche Begebenheiten nict die Ausnahme sind.
Und das waren große, bekannte Namen, deutsch und nordeuropäisch...

Inzwischen kostet es aber einen Preis, denn das hat sich in der
(hiesigen) Pannenstatistik gezeigt. Wer ein solides Auto braucht, sollte
ein japanisches kaufen. Weiss hier jedes Kind. Wer "was darstellen"
moechte, muss natuerlich eine europaeische Nobelkarosse haben. Doch auch
da broeselt es, Leute desertieren zu Lexus oder Infinity. Kunden, die
blieben, verlangen jetzt ellenlange Rundum-Garantien, inklusive Leihwagen.

--
Gruesse, Joerg

http://www.analogconsultants.com/

 

[Gerrit Heitsch]

On 10/29/2013 02:58 PM, Hanno Foest wrote:

Am 29.10.2013 14:27 schrieb Gerrit Heitsch:

Trotzdem sind heutige CPUs leider nicht
100% verifizierbar und eine neue Architektur dürfte sich nicht
durchsetzen können. x86/x64 funktioniert gut genug.

Das ist auch der Grund, warum keine Anstrengungen bzgl. verifizierbarer
Software unternommen werden: Es funktioniert gut genug, und für die
Fälle, wo es das nicht tut, gibt es Versicherungen.

Es funktioniert aber auch schlecht genug, so daß man den Leuten dauernd
was neues verkaufen kann. Und obendrein müßte Software zur automatischen
Verifikation quelloffen sein und das geht ja nun gar nicht.

Ich will mich dennoch nicht solchen Marktzwängen unterwerfen müssen.

Schön... Aber der Zug dürfte abgefahren sein. Oder wo bleibt das
komplett verifizierbare OS mit ähnlichem Funktionsumfang wie es heute
erwartet wird?

Gerrit

 

[Hanno Foest]

Am 29.10.2013 15:19 schrieb Gerrit Heitsch:

Schön... Aber der Zug dürfte abgefahren sein. Oder wo bleibt das
komplett verifizierbare OS mit ähnlichem Funktionsumfang wie es heute
erwartet wird?

Ich erwarte keinen Funktionsumfang wie heute. Wenn du aber (innerhalb
der Spec) beliebigen Code darauf ausführen kannst, dann kannst du auch
beliebige Dinge damit machen.

Hanno

 

[Ansgar Strickerschmidt]

Also schrieb 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?

Man macht einfach Zwei-Bit-Redundanz, d.h. man korrigiert 1-Bit-Fehler und
erkennt 2-Bit-Fehler.
Für kritische Anwendungen (Bahn bspw.) ist auch noch höhere Redundanz
gefordert. BTDT...

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?

Korrigieren. Und dann die Kiste geordnet in einen definierten
Failsafe-Modus bringen, wie auch immer der im Einzelfall aussieht
(automatisches sanftes Bremsen, Motor aus, gefährliche Bewegung eines
Anbauteils vulgo Baggerarms abstoppen, whatever...).

Ansgar

--
*** Musik! ***

 

[Gerrit Heitsch]

On 10/29/2013 05:04 PM, Thomas Stanka wrote:

Am Montag, 28. Oktober 2013 17:39:15 UTC+1 schrieb Frank Buss:
Marc Santhoff wrote:

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

Wird man zwar im Regelfall auch bei Flash so machen, aber meines Wissens ist die eigentliche Zelle nach dem Schreiben im Flash relativ sicher gemessen am restlichen System,

Hängt vom Flash ab. Aktuelles NAND-Flash (in SSDs benutzt) ist ohne ECC
unbenutzbar weil zuviele Fehler drin sind. Die kleinen Flash, die man
meist für Firmware nimmt sind problemloser.

Gerrit

 

[Hartmut Kraus]

Am 29.10.2013 01:30, schrieb Wolfgang Allinger:

On 28 Oct 13 at group /de/sci/electronics in article l4mc1k$562$1@newsreader4.netcologne.de
fb@frank-buss.de> (Frank Buss) wrote:

Michael Eggert wrote:

Laufen da auf 5 unterschiedlichen CPUs 5 Programme von 5 Entwickler-
teams, die mit 5 Compilern übersetzt wurden?

Ja, siehe die von Jörg zitierte Powerpoint-Präsentation:

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

Verschiedene CPUs, verschiedene Teams, sogar unterschiedliche
Computersprachen sollen eingesetzt worden sein.

Ja, kenne ich von Schmersal/Wuppertal. Die machen Sicherheitssteuerungen
u.a. für Aufzüge und Pressen. Da wurden wirklich 3 verschiedene uC,
Programmiersprachen und sowieso Teams genommen.

Die müssen wohl auch die Steuerung für den neuen Aufzug in unserem
Ärztehaus gebaut haben. Versuche nur mal als "Unkundiger", damit vom
Erdgeschoss in den 2. Stock zu kommen und da die Tür wieder aufzukriegen.

 

[Hartmut Kraus]

Am 29.10.2013 15:05, schrieb Joerg:

Ralph A. Schmid, dk5ras wrote:
Geht ja offenbar fast immer dennoch irgendwie gut, aber ein Gschmäckle
bleibt da schon, zumal solche Begebenheiten nict die Ausnahme sind.
Und das waren große, bekannte Namen, deutsch und nordeuropäisch...


Inzwischen kostet es aber einen Preis, denn das hat sich in der
(hiesigen) Pannenstatistik gezeigt. Wer ein solides Auto braucht, sollte
ein japanisches kaufen. Weiss hier jedes Kind. Wer "was darstellen"
moechte, muss natuerlich eine europaeische Nobelkarosse haben. Doch auch
da broeselt es, Leute desertieren zu Lexus oder Infinity. Kunden, die
blieben, verlangen jetzt ellenlange Rundum-Garantien, inklusive Leihwagen.
Das lässt uns hoffen.