mikrocontroller.net

Forum: Compiler & IDEs Sicherheitsrelevante Software


Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich implementiere im Moment eine sicherheitskritische Software für ein 
Produkt, bei welchem Menschen im schlimmsten Fall durch sehr heißes 
Wasser zu Verbrühungen kommen kann.
Die Software ist soweit fertig und auch alle Tests des 
Sicherheitskonzepts werden erfüllt.
Das ganze läuft in einem AVR und ist mit WinAVR in C geschrieben.
Jetzt der Knackpunkt: darf man für solche Software überhaupt den GCC 
verwenden!? Bin ich verpflichtet einen wie auch immer gearteten 
zertifizierten Compiler zu verwenden? Der Herr vom TÜV der die 
technische Sicherheit des Produktes überprüft konnte keine klare Aussage 
dazu treffen.

Habt Ihr schon mal sicherheitskritische Software mit dem GCC 
implementiert und seit auf die gleiche Problematik gestoßen?

Gruß
Stefan

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was ich noch von früher weiss, dass es solche Compiler gibt, aber die 
kann sich kaum eine Firma leisten. Ist bei dir eigentlich 
Codeoptimierung eingeschaltet?

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, die Codeoptimierung ist eingeschaltet.

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der AVG-GCC ist betriebserprobt. Ich weiss, dass er in Firmen teilweise 
für Anwendungen mit SIL4 verwendet wird.
Entscheident ist, dass es noch weitere Sicherungen gibt. Hierzu gehört 
z.B. das das System 2-Kanalig ausgelegt und diversitär programmiert 
wurde.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Software-Sicherheit ist immer relativ. Deshalb werden bei wichtigen 
Sachen auch 3 unabhänige Systeme verbaut. Wenn es nur um einen WW-Boiler 
geht, würde ich eine zusätzliche unabhängige Übertemperatursicherung 
einplanen.

Autor: Rogie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Sicherheitsrelevanten Sachen sollte man mind. 2 Prozessoren 
verwenden, die die Ergebnisse jeweils am besten noch mit 
unterschiedlichen Code (sprich A und B Code, von 2 Entwicklern) 
berechnen und die Ergebnisse vergleichen. Fällt dieses positiv aus, kann 
das Programm fortfahren, wenn nicht, muss die Einrichtung einen sicheren 
Zustand einnehmen.
Auch gewisse Programmierrichtlinien sind einzuhalten (z.B. ist 
dynamische Speicherreservierung verboten).

Vor allen musst du nachweisen können, ob deine Software in allen Fällen 
unkritisch ist, d.h. wenn, dann immer zu sicheren Seite ausfällt, in 
deinen Fall darf es also auf keinen Fall vorkommen, dass Menschen zu 
Schaden kommen können.

Als Beispiel Bahn AG: Es darf nicht vorkommen, dass bei Rechnerausfall 
ein Signal auf Fahrt geht, die Lokomotive auf Vollgas geht, usw.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich glaube Codeoptimierung ist auch tabu, weil man nicht weiss, was 
genau wegoptimiert wird

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rogie schrieb:
> Vor allen musst du nachweisen können, ob deine Software in allen Fällen
> unkritisch ist, d.h. wenn, dann immer zu sicheren Seite ausfällt, in
> deinen Fall darf es also auf keinen Fall vorkommen, dass Menschen zu
> Schaden kommen können.

Bei manchen Anwendungen ist es aber sehr schwierig oder unmöglich, solch 
einen sicheren Fall zu definieren, z.B. bei einem lebenserhaltenden 
System wie einem Beatmungsgerät oder einer Herz-Lungen-Maschine. Da muss 
man eher sicherstellen, dass das Gerät nach einem Fehlerzustand 
schnellstmöglich wieder funktionsfähig wird. Eine Sicherheitsabschaltung 
würde hingegen den sicheren Tod des Patienten bedeuten.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... schrieb:
> ich glaube Codeoptimierung ist auch tabu, weil man nicht weiss, was
> genau wegoptimiert wird

Man sollte während der Testphase (ohne Gefährdungspotential!) jedoch mit 
verschiedenen Optimierungseinstellungen herumspielen, um dadurch 
versteckte Programmierfehler aufzudecken.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rogie schrieb:
> Als Beispiel Bahn AG:

... oder Toyota ...

> Es darf nicht vorkommen, dass bei Rechnerausfall ein Signal auf Fahrt
> geht, die Lokomotive auf Vollgas geht, usw.

Andreas Schweigstill schrieb:
> Eine Sicherheitsabschaltung würde hingegen den sicheren Tod des
> Patienten bedeuten.

Na dann ist es doch ziemlich sicher ;-)

SCNR ... hab heute wohl meinen gehässigen Tag.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan schrieb:
> Der Herr vom TÜV der die
> technische Sicherheit des Produktes überprüft konnte keine klare Aussage
> dazu treffen.

Was ich mich schon länger frage:
Wie prüft jemand etwas, von dem er keine Ahnung hat?

Ich vermute mal, irgend jemand erstellt ne Checkliste und ein anderer 
hakt sie ab und dann ist die Sache gegessen.


Peter

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Was ich mich schon länger frage:
> Wie prüft jemand etwas, von dem er keine Ahnung hat?

Danke, Peter ;-)
Dazu kommt noch die Frage, wer ein Sicherheitskonzept erstellt, bei der 
nach Fertigstellung des Produktes solche Fragen auftauchen.

Also: Gelbe Seiten. Such dir jemanden, der sich damit auskennt.

Und sollte es für dein Produkt keine verbindlichen Sicherheitsnormen 
geben (was durchaus sein kann), tja, dann wirst du im Falle eines Falles 
vor Gericht erfahren, was du hätttest noch beachten können müssen.

Oliver

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Was ich mich schon länger frage:
> Wie prüft jemand etwas, von dem er keine Ahnung hat?

Derjenige prüft, ob bestimmte Formalismen eingehalten wurden. Der 
Zeitbedarf für deren Einhaltung geht natürlich von der 
Projektarbeitszeit ab, so dass es auf Grund des höheren Zeitdrucks sogar 
zu einer erheblichen Verschlechterung der Produktqualität kommen kann.

Bei einem Kundenprojekt habe ich solch einen Evaluierungsprozess 
mitgemacht. Da gab es Unmengen zu erfüllender Anforderungen, die zum 
Teil völlig unsinnig waren. Es wurde beispielsweise überprüft, ob der 
Raum mit den Netzwerkdruckern gegen unbefugten Zugang abgesichert war, 
damit Dritte keinen Blick auf Programmlisting werfen konnten. Dabei 
wurde nicht berücksichtigt, dass es sich bei der zu entwickelnden 
Software eh um (auf Grund der GPL) offenlegungspflichtige Quellen 
handelte. In den anzuwendenden Prüfvorschriften war so etwas jedoch nie 
berücksichtigt worden.

Insgesamt stelle ich immer wieder fest, dass bei sicherheitskritischer 
Software in einem erstaunlichen Maße Wert auf Geheimhaltung gelegt wird, 
was ja völliger Humbug ist. Gerade die wirklich unfähigen Entwickler 
finden solche Regelungen wiederum ganz toll, weil sie dadurch eine 
Argumentationshilfe gegen ein Review ihrer eigenen Quelltexte bekommen.

Autor: tuppes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan schrieb:
> darf man für solche Software überhaupt den GCC
> verwenden!?

Natürlich, grundsätzlich darf man das.

Wichtig ist ja nicht, dass die Software niemals niemals niemals abstürzt 
(das glaubt dir eh keiner), sondern dass das Gesamtkonzept sicher genug 
ist und dass auch bei einem Softwareabsturz (oder bei einem anderen 
zufälligen Fehler) niemand zu Schaden kommen kann.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Ich vermute mal, irgend jemand erstellt ne Checkliste und ein anderer
> hakt sie ab und dann ist die Sache gegessen.

So in etwa läuft es ab. Die Norm wird von anderen Leuten erstellt, als 
diejenigen die Schlussendlich Punkt für Punkt die beschriebenen Absätze 
abklopfen.

Oliver schrieb:
> Dazu kommt noch die Frage, wer ein Sicherheitskonzept erstellt, bei der
> nach Fertigstellung des Produktes solche Fragen auftauchen.

Das erstellte Sicherheitskonzept hat als letztendlich offene Frage, ob 
ein auf open source basierender Compiler Verwendung finden darf. Dieser 
Punkt wurde von mir nicht erkannt.
Asche auf mein Haupt! Wer müsste von uns da nicht an und an die Gelben 
Seiten konsultieren?

Oliver schrieb:
> Und sollte es für dein Produkt keine verbindlichen Sicherheitsnormen
> geben (was durchaus sein kann), tja, dann wirst du im Falle eines Falles
> vor Gericht erfahren, was du hätttest noch beachten können müssen.

Genau das ist der Puntk. Es existiert keine vorhandene Norm, in die das 
Produkt vollends hineinkatalogisiert werden kann und somit in diese oder 
jene Norm gepresst wird.

Aber das ist alles ja auch nicht die Frage gewesen, die da lautet:
GCC genutzt, diese Art von Software erstellt und Probleme damit an 
entsprechender Stelle bekommen.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und was nützt einem der tollste "zertifizierte" Compiler, den eigentlich 
nur eine winzige Zahl von Entwicklern benutzt und der durch keine 
öffentlichen Reviews gegangen ist?

GCC hingegen enthält zwar auch einige Bugs, aber man darf auch nicht 
vergessen, dass er auf um Größenordnungen mehr Plattformen eingesetzt 
und damit auch getestet wird.

Der einzige Vorteil eines "zertifizierten" Compilers besteht darin, dass 
man im Falle eines Fehlers bessere Chancen hat, eine Mitschuld einem 
Dritten in die Schuhe zu schieben.

Wenn es dann wiederum dem Compilerhersteller gelingen sollte, 
nachzuweisen, dass man in seinem Programm nicht strikt konform war zu 
dem vom Compiler unterstützten Sprachstandard (ANSI C Version x, MISRA C 
Version y), dann ist auch der Hersteller wieder aus der Haftung.

Aber das ganze ist wieder einmal "typisch deutsch". Wie häufig erlebe 
ich es, dass gerade Entscheider in Projektbesprechungen überhaupt nicht 
versuchen, ein Projekt erfolgreich umzusetzen, sondern lieber von 
vornherein einen Schuldigen für ein eventuelles Scheitern des Projektes 
festlegen wollen. Gerne bedienen sie sich dabei auch eines externen 
Mitarbeiters/Dienstleisters, der plötzlich die Missstände der letzten 
hundert Jahre verkorkster Entwicklung ausbaden soll.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schweigstill schrieb:
> Aber das ganze ist wieder einmal "typisch deutsch".

Na ja, nicht ganz. Der Nachweis, nach geltende Normen und nach bestem 
Wissen und Gewissen alles für die Sichereheit des Produktes 
erforderliche getan zu haben, rettet am Ende im Falle eines Falles die 
eigene Existenz. Da geht es weniger darum, im Vorfeld Schuldige zu 
suchen, sondern darum, im Ernstfall unbegründete Anschuldigungen 
widerlegen zu können.

Oliver

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sonst bleibt nur: die Kiste in ein "anerkanntes Prüflabor" zu geben, 
damit man einen Stempel mehr bekommt als Nachweis.

Ob der Compiler zugelassen ist oder nicht: ich kenne kaum ein Stück 
Software was jahrelang ohne Update absolut fehlerfrei arbeitete. Damit 
hast Du Wochen später das nächste Elend oder die nächste "Aufgabe".

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver schrieb:
> Da geht es weniger darum, im Vorfeld Schuldige zu
> suchen, sondern darum, im Ernstfall unbegründete Anschuldigungen
> widerlegen zu können.

Oh, da habe ich als Dienstleister schon ganz andere Erfahrungen gemacht, 
und zwar unabhängig davon, ob es sich um ein neues Projekt handelt oder 
eines, das durch jahrelanges Herumgepfusche schon am Abgrund steht. 
Teilweise wird durch entsprechend verklausulierte Vertragsbedingungen 
versucht, eine vollständige Risikoübertragung auf den Dienstleister 
durchzuführen. In anderen Fällen sind Kunden einfach nur blauäugig, 
indem sie meinen, durch den Zukauf eines Fremdproduktes oder einer 
Fremdleistung auch Probleme gelöst zu bekommen, die kein Teil der 
Beauftragung sind. Besonders stutzig werde ich auch dann, wenn Kunden 
einen Nachweis darüber verlangen, dass man eine ausreichende Liquidität 
besitzt, um ein Scheitern des gesamten Projektes bezahlen zu können.

Leider muss ich auch feststellen, dass Anfragen für die genannte Art von 
Projekten mittlerweile nicht mehr die Ausnahme sind, sondern die 
Mehrheit darstellen.

Natürlich kann man nicht daraus folgern, dass das auch für die Mehrheit 
aller überhaupt durchgeführter Projekte zutrifft. Externe 
Projektunterstützung wird eben selten angefragt, solange noch alles im 
grünen Bereich ist, sondern häufig erst in Krisensituationen.

Einen gewissen Anteil an Kunden muss ich jedoch von o.a. Vorwürfen 
freisprechen! Das sind solche, deren eigene Entwickler manchmal nicht 
mehr den Wald vor lauter Bäumen sehen, ein spezifisches technisches 
Problem haben und rechtzeitig externe Unterstützung - i.A. auch nur 
für einige Stunden oder Tage - anfordern. Interessanterweise sind das 
aber auch die eher kompetenten Entwickler.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt da einen kleinen Unterschied zwischen deutscher Wertarbeit und 
Vertragsgestaltung nach dem Motto "TÜV am Tag der Prüfung ok".

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also bei Flugnavigationssoftware etc. brauchst du zertifizierte 
Compiler, bei Haushaltsgeräten nicht, da verbrüht man sich ja schon an 
einem simplen Kochtopf.

Wenn aber das Haus abbrennt, weil dein uC ständig geheizt hat, zahlst du 
Schadenersatz. Es ist also immer ein unabhängig von Software arbeitender 
Sicherheitsmechanismus notwendig.

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal 'ne andere Frage: Wie wahrscheinlich schätzt ihr einen 
Compilerfehler als Fehlerursache im Vergleich zu einem Softwarefehler 
oder gar zum Hardwarefehler in diesem konkreten Fall ein? Genau.
Außerdem ist der Hersteller immer in der Produkthaftung. Wenn man ihm 
nicht grobe Fahrlässigkeit oder gar Vorsatz nachweist, ist seine 
Haftpflicht dran. Bzw. die wird evtl. erstmal zahlen und ihn dann in 
Regress nehmen. Viel wichtiger bei einer solchen Entwicklung ist, daß 
man die geltenden Normen und den Stand der Technik berücksichtigt hat, 
vernünftige Riskoanalysen mit entsprechenden Konsequenzen nachweisen 
kann (z.B. komplett separater Sicherheitschaltkreis zur Überwachung 
kritischer Parameter/Fehlerzustände), entsprechende Tests gemacht wurden 
und auch sonst ein "professionelles" (angemessenes) Vorgehen nachweisbar 
ist, wie z.B. nutzen der selben Compilerversion auch für eventuelle 
Updates (nicht nur im Produkt, hier unwahrscheinlich, sondern auch bei 
einer neuen Fertigungsreihe, nach dem Motto "baut auf 3-jähriger und 
600-fach bewährter Basissoftware auf.
Haftung ist, wie gesagt, klar, nur die anderen Punkte sind zivil- und 
vor allem strafrechtlich die ausschlaggebenden Punkte.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lutz schrieb:
> Mal 'ne andere Frage: Wie wahrscheinlich schätzt ihr einen
> Compilerfehler als Fehlerursache im Vergleich zu einem Softwarefehler
> oder gar zum Hardwarefehler in diesem konkreten Fall ein?

Genaugenommen ist es egal wieviele Fehler ein Compiler hat.

Was letztendlich zählt, ist der Code, der schlussendlich auf der 
Maschine laufen wird. Und das ist nicht C-Code, nicht Ada-Code, nicht 
Assembler-Code, und auch nicht Object-Code, sondern fertig gelinkter und 
lokatierter Maschinencode, der in einer bestimmten Ausführungsumgebung 
läuft (Wait-States für Speicherzugriff, Caching-Effekte, 
Pileline-Effekte, ...). Letztere sind für AVR allerdings nicht 
bedeutsam.

Praktisch jede sicherheitskritische Software muss echtzeitfähig sein, 
und um wasserdichte WCET-Analysen zu erhalten, müssen die Analysetools 
auf den Hex-Files arbeiten. Vieles können die Tools selbständig 
ableiten, aber eben nicht alles, und dann muss jemand, der sich mit der 
Software und der Hardware auskennt, dem Tool unter die Arme greifen 
(etwa bei indirekten Funktionsaufrufen, Obergrenze von 
Schleifeniterationen, ...)

Wahr ist allerdings, daß ein fehlerfreier, nicht-optimierender Compiler 
das Entwicklerleben deutlich vereinfacht oder sogar vorgeschrieben wird, 
welcher Compiler wie zu verwenden ist (Version, Zertifizierung, 
Verschalterung, Bugtracking, ...).

Neben der eigentlichen Software die laufen wird und der Hardware gehört 
allerdings auch das Entwicklungsumfeld zur Erstellung solcher Software, 
und es ist nicht ungewöhnlich, daß an den Entwicklungsprozeß selbst 
anforderungen gestellt werden, um eine Zertifizierung zu erhalten wie 
bestimmtes Qualitätsmanagement, Coding-Rules à la MISRA, etc.

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Johann.

> Neben der eigentlichen Software die laufen wird und der Hardware gehört
> allerdings auch das Entwicklungsumfeld zur Erstellung solcher Software,
> und es ist nicht ungewöhnlich, daß an den Entwicklungsprozeß selbst
> anforderungen gestellt werden, um eine Zertifizierung zu erhalten wie
> bestimmtes Qualitätsmanagement, Coding-Rules à la MISRA, etc.

Richtig. Und zertifiziert ist alles SAUTEUER und BÜROKRATISCH.
Wir werden im Moment auf Sicherheit angefixt wie auf Heroin. Wenn wir 
aber international mithalten wollen, müssen wir irgendwann von unseren 
hohen Standards RUNTER auf den von Entwicklungs und Schwellenländern.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic

http://www.dl0dg.de

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>zertifiziert ist alles SAUTEUER und BÜROKRATISCH
Muß aber nicht besser sein, wenn man dann die Fehler wegen irgendeiner 
Zertifizierung nicht so einfach beseitigen kann.

Wichtiger als irgenwelche Stempelchen scheint mir, daß sich die Software 
an bestimmten Stellen selbst auf Plausibilität prüfen kann. Damit erhöht 
die Qualität. Durch Updates oder neue Compiler eingeschlichene 
Veränderungen werden dann evtl. vor der Katastrophe bemerkt.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan schrieb:
> Jetzt der Knackpunkt: darf man für solche Software überhaupt den GCC
> verwenden!? Bin ich verpflichtet einen wie auch immer gearteten
> zertifizierten Compiler zu verwenden? Der Herr vom TÜV der die
> technische Sicherheit des Produktes überprüft konnte keine klare Aussage
> dazu treffen.

Zuerst sollte mal geklärt werden, welchen Normen und Gesetzen Dein 
Produkt bzw. dessen Inverkehrbringen genügen muss. Sind dort keine 
klaren Regeln für Deine Frage beschrieben, läuft es wohl auf "Stand der 
Technik" und "proven in use" hinaus. Das heißt, es sind in dem Bereich 
allgemein übliche und verwendete technische Maßnahmen anzuwenden. Eine 
klare Antwort diesbezüglich gibt es also nicht, weil das vom konkreten 
Fall abhängt.

Als Beispiel die Automobiltechnik: Hier werden in der Regel 
"qualifizierte" Compiler eingesetzt. Ob deren Fehlerrate aber wirklich 
unterhalb der Rate vom gcc liegt, bezweifle ich. Das Entwicklungsmodell 
solcher Compiler kann meines Erachtens nach nicht mit einer offenen 
Entwicklung mithalten. Aber in die üblichen Prozesse passt eben ein 
qualifizierter Compiler besser.

Zusätzlich zu den Compilern stellt sich auch noch die Frage nach der 
Implementierung selber. Also die Programmierung (in der Automobiltechnik 
sind die MISRA-Regeln maßgebend), das im Design liegende 
Sicherheitskonzept (also im Fehlerfall soll das System in einen sicheren 
Zustand gehen) und evtl. irgendwelche zusätzlichen 
Sicherheitseinrichtungen, die Fehlerzustände erkennen und das System in 
einen sicheren Zustand versetzen. Wie oben schon beschrieben empfehlen 
sich da schon mehrstufige und evtl. parallele oder eigenständige 
Sicherheitseinrichtungen.
Eine gute Idee ist meines Erachtens auch, dass man die gesamte 
Sicherheitsstrategie gut dokumentiert und mit dem Kunden (wenn nicht 
gerade Endkunde) abspricht bzw. zum Teil der Abnahme macht.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino G. schrieb:
> Eine gute Idee ist meines Erachtens auch, dass man die gesamte
> Sicherheitsstrategie gut dokumentiert und mit dem Kunden (wenn nicht
> gerade Endkunde) abspricht bzw. zum Teil der Abnahme macht.

Technisch sinnvoll, um auch Jahre später noch brauchbare Unterlagen zu 
haben. Es sollte nur kein Rechtsverdreher gegen Dich verwenden können.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oszi40 schrieb:
> echnisch sinnvoll, um auch Jahre später noch brauchbare Unterlagen zu
> haben. Es sollte nur kein Rechtsverdreher gegen Dich verwenden können.

Genau die Rechtsverdreher sind ja Ziel einer solchen Maßnahme. Macht man 
das Sicherheitskonzept zum Teil der Abnahme durch den Kunden (wenn nicht 
Endkunde!), verteilt man die Verantwortung schon mal auf mehrere 
Schultern. Die Systemverantwortung trägt ja, wenn es um eine Art 
Zuliefererverhältnis und nicht um Lieferungen an Endkunden geht, ohnehin 
der OEM. Hinzu kommt, dass eine vernünftige Dokumentation der 
Sicherheitsstrategie bei späteren Prozessen durchaus hilfreich sein 
kann, um nachzuweisen, dass man sich mit dem Thema beschäftigt hat und 
das zu diesem Zeitpunkt technisch und wirtschaftlich Machbare getan hat.
Natürlich ist das alles keine Garantie gegen Prozesse und Kosten, aber 
allemal besser als dann mit leeren Händen dazustehen.

Autor: Rogie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schweigstill schrieb:
> Bei manchen Anwendungen ist es aber sehr schwierig oder unmöglich, solch
> einen sicheren Fall zu definieren, z.B. bei einem lebenserhaltenden
> System wie einem Beatmungsgerät oder einer Herz-Lungen-Maschine. Da muss
> man eher sicherstellen, dass das Gerät nach einem Fehlerzustand
> schnellstmöglich wieder funktionsfähig wird. Eine Sicherheitsabschaltung
> würde hingegen den sicheren Tod des Patienten bedeuten.

Da geht man dann über Redundanz, z.B. sind im Flugzeug mehrere Systeme 
für ein und diesselbe Aufgabe vorhanden, meines wissens nach mind. 3. 
Wenn 2 das richtige Ergebnis liefern und eins nicht, so wird das 
fehlerhafte System ausgeschaltet und die restlichen zwei Systeme 
übernehmen dann die Aufgabe. Fällt dann noch eins aus: Keine Ahnung, wie 
dann verfahren wird.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rogie schrieb:
> Da geht man dann über Redundanz, z.B. sind im Flugzeug mehrere Systeme
> für ein und diesselbe Aufgabe vorhanden, meines wissens nach mind. 3.
> Wenn 2 das richtige Ergebnis liefern und eins nicht, so wird das
> fehlerhafte System ausgeschaltet und die restlichen zwei Systeme
> übernehmen dann die Aufgabe. Fällt dann noch eins aus: Keine Ahnung, wie
> dann verfahren wird.

Ich würde mal sagen, dass dann der Bediener übernehmen muss. Im Flugzeug 
wird es laut klingeln, um die Piloten wieder zu wecken und soweit ich 
weiß, gibt es bei der Herz-Lungen-Maschine auch einen Handbetrieb. Da 
wird der Kardiotechniker dann in's Schwitzen kommen. :D

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rogie schrieb:
> Da geht man dann über Redundanz, z.B. sind im Flugzeug mehrere Systeme
> für ein und diesselbe Aufgabe vorhanden, meines wissens nach mind. 3.

Über die Syteme im A380 war mal ein Artikel in der c't. Da sind alle 
kritischen Syssteme dreifach vorhanden, und zwar alle nach der selben 
Spezifikation erstellt, aber unterschiedliche Hardware und unabhängig 
von einander geschriebene Software verwenden.
So vermeidet man Situationen, in denen derselbe Fehler (Prozessor-Bug, 
Schaltungs-Fehler, Software-Fehler, Compiler-Fehler, ...) bei allen drei 
Systemen gleichzeitig zuschlägt.

> übernehmen dann die Aufgabe. Fällt dann noch eins aus: Keine Ahnung, wie
> dann verfahren wird.

Gastino G. schrieb:
> Ich würde mal sagen, dass dann der Bediener übernehmen muss.

Es handelt sich aber um Systeme, die zwischen Bediener und den Rudern 
der  Maschine sind. Fallen die aus, müßte der Bediener schon rausgehen 
und die Ruderklappen mit der Hand in die Zielstellung drücken.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob TS Stefan nun für seine neue Wärmflasche wirklich 3 unabhängige 
Systeme braucht?

Als ich zur Steinzeit der Computer mal einen kleinen Compiler-Test 
gemacht habe, hatte ich hinterher statt 3 Zeilen Code stattliche 12k 
Code, die nicht mal das selbe taten. Wieso sind wir da heute 
optimistischer?

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde dazu sagen:
110% Dokumentation für alles, von PC-Konfiguration, Tools-Konfiguration, 
..., Risikoanalyse  bis Projekt selber - "... wenn Geschwindigkeit > 
110, eine rote Lampe brennt ..." und ein Link auf „Blockdiagramm“. Von 
hier wieder ein Link auf den Code (alles machbar mit DOORS):

 if (speed > 110)
  RedLamp = true;

Für die Tests: funktionale Tests (Unit Tests) und Code Coverage (MCDC, 
Branch coverage). Man sollte auch ein „Language Subset“ verwenden, d.h. 
z.B. MISRA und einen „amtlich“ anerkannten MISRA Checker (Q&C, …). Ab 
IEC 61508 SIL3 eine statische Codeanalyse durchzuführen (die Norm sagt 
"Highly reccomended"). Für alles am besten „Qualified“ Werkzeuge 
einsetzen (noch besser Certified, die aber nicht existieren oder 
unbezahlbar sind). Man kann auch ne gcc selber qualifizieren. Es sind 
50-100 Seiten Beschreibung und ~10.000 Tests Patterns.
Es ist alles machbar, aber praktisch als Einzelperson nicht bezahlbar. 
Unsere Firma verkauft ein „Qualifikation Kit“, wo schon 75% fertig ist 
für ~10k €. Aber ohne der Vorkenntnisse mit TÜV & Co. immer noch seeeehr 
schwierig.
Apropos: in SIL2 sind Einzelpersonen verletzt, in SIL3 sind mehrere 
Personen betroffen.

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rogie schrieb:
> Wenn 2 das richtige Ergebnis liefern und eins nicht, so wird das
> fehlerhafte System ausgeschaltet

Für Verkehrsflugzeuge ist es Vorschrift, existentielle Systeme 3-fach 
redundant vorzuhalten. Aber automatisch abgeschaltet wird da gar nichts, 
daß müssen die Flugzeugführer schon selbst tun. Es wird (zumindest 
wurde) noch nicht einmal ein Plausibilitätstest der 3 Systeme 
untereinander im Betrieb durchgeführt. Sonst wäre z.B. Birgen Air nicht 
in die Karibik geknallt: Ein Fahrtmesser zeigte eine viel zu hohen 
Wert an. Unglücklicher Weise wurde dieser Fahrtmesser des Pilot Flying 
auf den Autopiloten geschaltet und der Schub durch diesen so weit 
verringert, daß die Maschine einen Strömungsabriß bekam. Paradoxer Weise 
alarmierten andere Systeme zeitgleich und absolut widersprüchlich: MACH 
TRIM SPEED (Overspeed) und STALL WARNING (zu langsam, Strömungsabriss) 
sowie der Stickshaker (Vibrieren des Steuerknüppels) kamen. Das 
verwirrte die Piloten. Hätten die allerdings schon beim Start richtig 
reagiert, wäre nix passiert. Der nicht fliegende Pilot glotzt da nämlich 
nur auf die Instrumente und macht Ansagen. U.a. sagt er, wenn sein 
Fahrtmesser 80 Knoten anzeigt, dies an. In dem Moment glotzt der Pilot 
Flying auf seinen und bestätigt dies (üblicherweise). Und hier sagte er 
"check ..., äh, doch nicht)" ... . Ich schweife ab.

Oder auch bei Lauda-Air: Mitten im Flug kommt der Umkehrschub bei einem 
Triebwerk ... . Mit Plausibilitätstests wär das alles nicht passiert.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wie wahrscheinlich schätzt ihr einen Compilerfehler
> als Fehlerursache im Vergleich zu einem Softwarefehler
> oder gar zum Hardwarefehler in diesem konkreten Fall ein?

Compilerfehler kommen vor, sie waren z.B. der Grund warum wir von 
Borland C zu Microsoft C gewechselt sind (Microsfot C wurde für VIEL 
mehr Implementationen verwendet und war wohl deswegen fehlerfreier), 
aber auch unter Microsoft C und diversenen anderen sind uns Fehler 
begegnet, teils im erzeugten Code (die man dann durch herunterstufen der 
Optimierungen loswerden konnte) teils in der Implementation der 
Standardbibliothek (die man durch nicht-verwenden der fehleraften 
Funktionen umgehen konnte) und bei Mainframe-Copmilern auch gnadenlos 
durch Fehlinterpretation von gültigen Sprachkonstrukten (*i++ ging 
nicht). Compilerfehler sind also gar nicht so selten, und ncht alle 
fallen in Tests auf (weil man ja gar nicht so genau weiss, auf welche 
Grenzfälle man testen soll).

Hardwarefehler  im CPU Chip sind eher selten geworden, aber daß 
Schaltungen wegen Störungen aussteigen, gibt's öfters.

Natürlich sind die allermeisten Fehler von den Programmierern 
verursacht. Die sind aber wenigstens behebbar.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schrieb:
> Der AVG-GCC ist betriebserprobt. Ich weiss, dass er in Firmen teilweise
> für Anwendungen mit SIL4 verwendet wird.

grmpf Nachdem ich gestern auch selbst noch auf die Erprobtheit des GCC 
verwiesen hatte, wurde ich gestern höchstpersönlich eines besseren 
belehrt...

Ein Fehler, der schon seit längerem bei einem bestimmten Softwarestand 
unseres Projektes bekannt war und den ich mir selbst durch wiederholten 
scharfen Blick auf den Quellcode nicht erklären konnte, bestand in 
fehlerhaftem Code, den der WinAVR-100110 erzeugt hat. Eventuell war es 
auch der Linker. Feststellen konnte ich den Fehler nur, weil ich im 
Disassembler-Listing jede C-Instruktion auf Übereinstimmung hin 
kontrolliert hatte.

Der Fehler bestand darin, dass im generierten Code die Adresse einer 
Variable falsch berechnet wurde. Dadurch wurde eine Bitmaske falsch 
berechnet. Nein, ich habe keine Typecasts mit unüberschaubaren 
Seiteneffekten verwendet.

Schon minimale Modifikationen des Quellcodes lassen den Fehler 
verschwinden.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tom schrieb:
> (alles machbar mit DOORS)

Ismirschlecht... :D

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schweigstill schrieb:
> bestand in
> fehlerhaftem Code, den der WinAVR-100110 erzeugt hat. Eventuell war es
> auch der Linker.

Gibt es dazu ein nachvollziehbares Beispiel?

Oliver

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schweigstill schrieb:
> Der Fehler bestand darin, dass im generierten Code die Adresse einer
> Variable falsch berechnet wurde.

Bitte unbedingt gucken, ob's dafür schon einen Bugreport gibt,
ansonsten berichten.  Bugs, bei denen warnungslos falscher Code
erzeugt wird, sollten eigentlich eine hohe Priorität erhalten.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver schrieb:
> Gibt es dazu ein nachvollziehbares Beispiel?

Ich habe heute versucht, diesen Fehler nachzustellen, indem ich exakt 
den Versionsstand der Quellcodes ausgecheckt habe, in dem der Fehler 
auftrat. Selbstverständlich habe ich auch dieselbe Toolchain-Version auf 
demselben Rechner verwendet.

Leider lässt sich das Verhalten nicht reproduzieren. Es ist jedoch vor 
mehreren Wochen und vor einigen Tagen definitiv aufgetreten.

Somit kann ich derzeit leider keine Hinweise für die Fehlerkorrektur des 
GCC geben. :-(

Autor: Visitor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn deine Software sicherheitsrelevant ist, dann lautet die 
Fragestellung nicht darf ich den GCC verwenden ! Laut deiner Aussage ist 
die Software eh fertig, d.h. die Frage hätte vor der Implementierung 
gestellt werden müssen !

Vielmehr lautet die Frage : Wonach bzw. wie muss die Software geprüft 
bzw. zertifiziert werden ?

Wenn die Software einer Norm etc. unterliegt, dann gibt es auch eine 
Richtlinie hierfür ! Solltest du diese erst noch in Erfahrung bringen 
müssen, dann hast du ein riesen großes Problem. Da ich mir nicht 
vorstellen kann, dass du beim Programmieren so gut geraten hast um die 
Richtlinie zu erfüllen. In der Richtlinie steht evtl. auch eine 
Anmerkung zum Compiler bzw. zur Optimierung.

Generell gilt : Bei sicherheitsrelevanter Software muss man seine 
Hausaufgaben VOR der Codeumsetzung machen, da hier das Gesamtkonzept 
stimmen muss !!!

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
*Plenk!*

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...also hier die Antwort vom TÜV:


> grundsätzlich besteht kein Problem [...bei der Verwendung des GCC]. Der
> Kunde sollte sich aber für eine Version entscheiden (wie Sie ja schon
> geschrieben haben), die Einsatzbedingungen kennen, Erfahrung damit haben
> und die bug list beachten.

Ich muss zugeben: ich bin erleichtert!

Werde den teilweise gefallenen Ratschlägen in Zukunft mehr Beachtung 
schenken.

Gruß
Stefan

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schweigstill schrieb:

> scharfen Blick auf den Quellcode nicht erklären konnte, bestand in
> fehlerhaftem Code, den der WinAVR-100110 erzeugt hat.

Unter uns Klosterschwestern:

Ich lese ja jetzt schon eine ganze Weile hier im Forum mit. Aber was 
sich da im Laufe der Zeit an Bugs im WinAVR offenbart haben ... lies mir 
ehrlich gesagt manchmal die Haare zu Berge stehen.

Manchmal war ich schon schwer am zweifeln, ob ich die Aussage 'Geh davon 
aus, dass ein Laufzeitfehler zu >99% im Usercode und nicht im Compiler 
seine Ursache hat' noch aufrecht halten soll.

Aber das sag ich nur unter vorgehaltener Hand :-)

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Aber was
> sich da im Laufe der Zeit an Bugs im WinAVR offenbart haben ... lies mir
> ehrlich gesagt manchmal die Haare zu Berge stehen.

Allerdings war bisher keiner dabei, der sich nicht reproduzieren liess. 
Diese Sorte Bug wäre nämlich ganz übel.

Oliver

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Manchmal war ich schon schwer am zweifeln, ob ich die Aussage 'Geh davon
> aus, dass ein Laufzeitfehler zu >99% im Usercode und nicht im Compiler
> seine Ursache hat' noch aufrecht halten soll.

Die 99 % werden schon noch stimmen, nur die Masse ist mittlerweile
einfach größer geworden, sodass das 1 % häufiger mal zuschlägt.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Karl heinz Buchegger (kbuchegg) (Moderator)

>sich da im Laufe der Zeit an Bugs im WinAVR offenbart haben ... lies mir
>ehrlich gesagt manchmal die Haare zu Berge stehen.

Beispiele?

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver schrieb:
> Allerdings war bisher keiner dabei, der sich nicht reproduzieren liess.
> Diese Sorte Bug wäre nämlich ganz übel.

Noch übler, wenn's garkein Bug ist ;-)

Ich hatte neulich das erste Mal das "Vergnügen", einem Bitkipper von der 
sporadischen (also nicht mit einem Defekt verbundenen) Sorte bzw. dessen 
Auswirkungen durch Zufall quasi "live" zuzugucken.

Ein Cronjob, der alle 5 Minuten ein paar Dateien aus einer Datenbank 
generiert, hat einmalig einen Output generiert, der sich in genau einem 
Bit vom vorherigen unterschied, 5 Minuten später (nach dem nächsten 
Lauf) war alles wieder zurück zum alten. An der Datenbank selbst hat 
sich natürlich nachweislich in der fraglichen Zeit nichts geändert.

Derartige Fehler treten bei einem durchschnittlichen Rechner mit 
Nicht-ECC-Speicher AFAIK inzwischen alle paar Tage auf, je nachdem 
welche Zelle genau kippt, kann das von einem kompletten Non-Event bis 
hin zu dauerhaft verfälschten Daten alles bedeuten. Auch Fehler, die 
nach ein paar Stunden oder Tagen von alleine auf Nimmerwiedersehen 
verschwinden sind da möglich, wenn z.B. ein Bit in der Cache-Kopie des 
gcc-Binaries gekippt ist, wirkt sich das solange aus, bis die fragliche 
Page irgendwann mal zufällig aus dem Cache geworfen und neu von der 
Platte geladen wird (wenn der gcc häufig benutzt wird und der Rechner 
durchläuft, kann das durchaus ein paar Tage dauern!).

Andreas

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Andreas Schweigstill schrieb:
> Leider lässt sich das Verhalten nicht reproduzieren. Es ist jedoch vor
> mehreren Wochen und vor einigen Tagen definitiv aufgetreten.

Andreas Ferber schrieb:
> Ich hatte neulich das erste Mal das "Vergnügen", einem Bitkipper von der
> sporadischen (also nicht mit einem Defekt verbundenen) Sorte bzw. dessen
> Auswirkungen durch Zufall quasi "live" zuzugucken.

Ich habe weiterhin versucht, das von mir aufgeführte Problem zu 
reproduzieren, aber das ist mir bislang nicht gelungen. Ich habe 
mittlerweile sogar Backups meiner Arbeitskopie von Tagen zurückgespielt, 
an denen ich dachte, dass dort der Fehler vorhanden gewesen sein konnte.

Nun habe ich jedoch noch ein programmiertes Gerät herumliegen, bei dem 
der beschriebene Fehler vorliegt. Ich kann ggf. noch versuchen, sein 
Flash auszulesen.

Ich kann jedoch definitiv ausschließen, dass der Fehler beim 
Programmieren des ATtiny verursacht wurde, da er an einem Tag auch im 
AVR-Simulator zu beobachten war.

Hmmm...

Autor: klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Ferber schrieb:
> Ich hatte neulich das erste Mal das "Vergnügen", einem Bitkipper von der
> sporadischen (also nicht mit einem Defekt verbundenen) Sorte bzw. dessen
> Auswirkungen durch Zufall quasi "live" zuzugucken

Habe mir darüber noch nie wirklich Gedanken gemacht, aber bin neugierig: 
Woher weißt du dass es nicht ein (zugegeben: ungewöhnlicher) 
Softwarefehler war? Sind "Bitkipper" ernstzunehmende Probleme im 
Mikrocontroller Bereich? Jemand da Erfahrungen ?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> @  Karl heinz Buchegger (kbuchegg) (Moderator)
>
>>sich da im Laufe der Zeit an Bugs im WinAVR offenbart haben ... lies mir
>>ehrlich gesagt manchmal die Haare zu Berge stehen.
>
> Beispiele?

Ich finde jetzt dir entsprechenden Threads nicht mehr.
Aber gab es da nicht letztes Jahr mal irgendwas mit Floating Point?
Vom (ich glaube) PeDa kann ich mich erinnern, wurde berichtet, dass der 
gcc HighByte und LowByte durcheinander geworfen hat.
Es waren schon ein paar Versionen dabei, die kurze Zeit später wegen (im 
Grunde sogar einfachen) Bugs durch neue ersetzt wurden.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind die internen Busse der AVRs ECC gesichert, gibt es 
Machine-check-exeptions ?

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klaus schrieb:
> Woher weißt du dass es nicht ein (zugegeben: ungewöhnlicher)
> Softwarefehler war?

Zu 100% weiss ich es natürlich nicht, dazu sind heutige Systeme einfach 
zu komplex. Aber zu 99%, (auch) wegen Occam's Razor.

Es war ein einzelnes Zeichen mitten in einem String falsch (und zwar ein 
"e" (0x65) durch ein "a" (0x61) ersetzt, also ein Bit Unterschied), der 
aus der Datenbank abgefragt und unverändert ausgegeben wird. Der Rest 
des Strings war OK, ebenso alle anderen Datensätze davor und danach, die 
in einer Schleife und damit alle vom gleichen Code ausgegeben werden.

Die Datenbank wurde wie gesagt definitiv nicht verändert (die letzte 
Änderung war ein paar Tage vor dem Ereignis), das Script ist in Perl 
geschrieben (sprich stray pointer oder buffer overflows bei der 
Stringverarbeitung quasi ausgeschlossen), das Script läuft seit Jahren 
ohne Änderung und ohne Probleme alle 5 Minuten, es trat nur ein einziges 
Mal auf, und noch diverse andere Details, die alle zu dem Schluss 
führten, dass ein solcher Softwarefehler derart obskur wäre, dass ein in 
der Hardware gekipptes Bit die naheliegendere Erklärung ist.

Andreas

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Karl heinz Buchegger (kbuchegg) (Moderator)

>> Beispiele?

>Ich finde jetzt dir entsprechenden Threads nicht mehr.

Tja, und genau HIER gehts nämlich los. Hier trennt sich die Spreu vom 
Weizen, Wissenschaft von Dummfang, Forensmalltalk von Substanz.

Entweder, man kann einen Fehler klar belegen und reproduzieren, oder es 
bleibt bei einer lauen Vermutung.

In dubio pro reo.

Das Gleich gilt für Andreas Ferber (aferber). Solche "ach was, jetzt 
find ich die Version nicht mehr, aber jetzt geht alles, alles komplex" 
nützt niemandem was. Das ist Stammtischgeschwätz. Entweder das 
reproduzierbare Problem, oder wenigsten der vermutlich fehlerhafte Code, 
auf den Tisch oder Sendepause.

MFG
Falk

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Das Gleich gilt für Andreas Ferber (aferber). Solche "ach was, jetzt
> find ich die Version nicht mehr, aber jetzt geht alles, alles komplex"
> nützt niemandem was.

Das habe ich nicht geschrieben.

> Entweder das
> reproduzierbare Problem, oder wenigsten der vermutlich fehlerhafte Code,

Das ist doch genau der Punkt. Der Fehler ist belegbar (die generierten 
Dateien werden wenn sich etwas geändert hat in ein Subversion-Repository 
eingecheckt), aber definitiv nicht reproduzierbar (der Fehler trat 5 
Minuten vorher und 5 Minuten nachher bei unveränderten Inputdaten und 
unverändertem System nicht auf). Und ja, ich weiss exakt mit welcher 
Version des Scriptes das auftrat, die läuft nämlich bis heute immer noch 
alle 5 Minuten fehlerfrei ;-)

Einen (obskuren) Fehler im Script selbst kann ich ausschliessen, bei 
einem kurzen Perl-Script, das eine SQL-Abfrage abfeuert und das Ergebnis 
formatiert ausgibt kann man nicht so wahnsinnig viel falsch machen, vor 
allem nichts, was bei identischem Input einmalig zu einem einzelnen 
geänderten Zeichen im Output führt. Bleiben theoretisch Perl, MySQL, 
Subversion und das Linux, auf dem das ganze läuft, als mögliche Quellen 
für einen richtig merkwürdigen Softwarefehler. Diese Millionen Zeilen 
Code (deshalb "komplex") habe ich nicht genauer untersucht, deshalb 
kann ich einen Softwarefehler eben nur zu 99% und nicht zu 100% 
ausschliessen.

Dass sporadische Bitkipper bei DRAM vorkommen ist ein Fakt, es ist nur 
ungewöhnlich, das mal so direkt zu sehen.

Andreas

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Ferber schrieb:
> Dass sporadische Bitkipper bei DRAM vorkommen ist ein Fakt

Naja, klassisch traten diese auf, wenn ein alpha-Teilchen einen
Speicherkondensator getroffen hat.  Das kann nicht mehr passieren,
seit dRAMs nicht mehr in Keramikgehäusen sitzen, denn bereits 50 µm
Polymerschicht genügen, um herumfliegende alpha-Teilchen sicher
auszubremsen.  Die Vergussmasse heutiger Gehäuse ist viel dicker.

Wenn heute also noch Bitkipper auftreten, dann deutet das eher auf
ein schlechtes Design der Schaltung, schlechte Abblockung etc. hin.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Naja, klassisch traten diese auf, wenn ein alpha-Teilchen einen
> Speicherkondensator getroffen hat.  Das kann nicht mehr passieren,
> seit dRAMs nicht mehr in Keramikgehäusen sitzen, denn bereits 50 µm
> Polymerschicht genügen, um herumfliegende alpha-Teilchen sicher
> auszubremsen.  Die Vergussmasse heutiger Gehäuse ist viel dicker.

Stichwort C14. Die Gehäusemasse selbst ist Quelle von ionisierender 
Strahlung, zwar Beta-Strahlung, aber auch die ist energiereich genug um 
bei einem "Volltreffer" einen Speicherkondensator zu entladen. Ausserdem 
können natürlich auch Alphastrahler in geringen Mengen bei der 
Produktion ins Gehäusematerial gelangen.

Woher die Speicherfehler genau kommen ist hier aber auch erstmal egal. 
Von Google gibt's ein Paper dazu, wo sie mal über 2,5 Jahre die 
Speicherfehler auf ihren Systemen (bekanntlich eine gewaltige Menge) 
gesammelt und statistisch ausgewertet haben, durchaus lesenswert:

http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

Andreas

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Andreas Ferber (aferber)

>Und ja, ich weiss exakt mit welcher
>Version des Scriptes das auftrat, die läuft nämlich bis heute immer noch
>alle 5 Minuten fehlerfrei ;-)

Dann poste den AVR Code und das Script. Es kann druchaus ein böser 
sporadischer Fehler sein, welcher durch Race Conditions in unsauber 
gehandhabten Interrupts auftritt. Stichwort atomar und volatil.
Das Bitkippen ist zwar eine einfache, meistens aber falsche Erklärung.

MFG
Falk

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Dann poste den AVR Code und das Script. Es kann druchaus ein böser
> sporadischer Fehler sein, welcher durch Race Conditions in unsauber
> gehandhabten Interrupts auftritt.

Wo schrieb ich, dass sich ein AVR auch nur im gleichen Raum befand, als 
mein Fehler auftrat? Ich heisse zwar auch Andreas, aber der Nachname ist 
anders als bei dem mit dem AVR-Problem ;-)

Noch einmal kurz: MySQL-Datenbank (unverändert), Perl-Script (ohne 
Nebenläufigkeit etc., einfach gerade runter SQL-Abfrage -> Schleife mit 
Ausgabe), Output einmalig verändert. Race Conditions ausgeschlossen, es 
lief definitiv nichts anderes, was zu dem Zeitpunkt auf die Datenbank 
zugegriffen hat.

Andreas

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> @  Karl heinz Buchegger (kbuchegg) (Moderator)
>
>>> Beispiele?
>
>>Ich finde jetzt dir entsprechenden Threads nicht mehr.
>
> Tja, und genau HIER gehts nämlich los. Hier trennt sich die Spreu vom
> Weizen, Wissenschaft von Dummfang, Forensmalltalk von Substanz.


Im Gcc Forum gibt es ein paar Threads, die letztendlich auf der 
Gcc-Bugliste gelandet sind.

Beitrag "Bug in WinAVR oder liegts an mir?"
Beitrag "GCC: code funktioniert bei -O, funktioniert nicht bei -Os"

Ich bin jetzt nur 1 Jahr zurückgegangen und hab sicherlich noch ein paar 
andere Threads übersehen. Aber insbesondere der erste der genannten Bugs 
ist einer, der nicht passieren darf.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Das Bitkippen ist zwar eine einfache, meistens aber falsche Erklärung.

Prinzipiell gebe ich dir da BTW auch recht, und wenn der Fehler während 
der Entwicklung aufgetreten wäre, hätte ich auch ein bisschen intensiver 
nach anderen Ursachen gesucht.

Nur wenn bei einem seit Jahren problemlos laufenden, recht einfach 
aufgebautem (Perl, MySQL, Linux an sich aussen vor) Stück Software 
einmalig ein derartiger Fehler auftritt, kann es eben auch mal die 
einfache Erklärung sein. Und wenn er in drei Jahren nochmal auftritt, so 
what. An dem Ding hängen keine Menschenleben.

Andreas

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.