Unkonventionelle Fehler In Hardware und Software

Bedeutung Unkonventionell: „nicht so, wie es allgemein üblich ist“[1] Gegensatz: Konventionelle Fehler Keine vollständige Beispielsammlung

Murphy der Optimist “If anything can go wrong, it will go wrong.” “… and, if anything can’t go wrong, it will go wrong anyway.” “accidents are almost always the result of incorrect estimates of the likelihood of one or more things.” Quelle [2]

Problem Erfahrungswerte: Falsche Annahmen (tritt sowieso nie auf) Anforderung >> Entwicklungszeit 5000 Stunden << 1 Fehler in 1.000.000.000 Stunden Entwicklung ≠ Reparatur, Wartung Kein Einblick in laufenden Prozess, Reparatur, Austausch Man bekommt keine defekten Einheiten zu sehen Arroganz Es gibt keine Fehler, die ich nicht kenne Transiente Fehler, nicht reproduzierbar

Problem Abstraktion Spezialisierung Aufteilen des Problems in mehrere Schichten mit mehr/weniger Details Fehler können in Schichten auftreten, die der Designer nicht sieht Spezialisierung Aufteilung des Problems in Teile von unterschiedlichen technologischen Disziplinen Fehler können sich in den „cracks“ der Disziplinen verstecken

Vorbild Chemieindustrie U.S. Chemical Safety Board untersucht Unfälle und veröffentlicht Fehlerberichte zur zukünftigen Fehlervermeidung Nicht üblich in der Elektronik Industrie Websites in Flugzeugindustrie[3][4][5] Softwarefehler auf Wikipedia „List of Software Bugs“[6]

Vermeidung Veröffentlichungen lesen Aus (eigenen) Fehlern lernen Selten zugänglich Zeitmanagement Aus (eigenen) Fehlern lernen Bug Reports immer ernst nehmen Abwegig denken möglichst keine Annahmen treffen Immer skeptisch sein

Byzantinische Fehler Ursprung aus der Theorie

Transmogrification STS-124 Fuel loading Complete system disagreement Quelle [7]

Transmogrification „The act of changing into a different form or apperance often as if by magic“ Quelle [7]

Irrglaube der „Digitalen Schaltung“ Quelle [8]

Irrglaube der „Digitalen Schaltung“ Quelle [7]

Schrödingers CRC Quelle [8]

Mid-Value Select Quelle [7]

Terminierungswiderstand Quelle [7]

Fehlerpropagation Hardware zu Software Software zu Hardware Software geht immer von korrekt arbeitender Hardware aus Software zu Hardware Software kann Hardware gewollt (Angriff) oder ungewollt schädigen (Auslastung, Malware, …)

Swiss Cheese Model Videoquelle [9]

Swiss Cheese Model Aus dem Gesundheitswesen Käsescheiben: Sicherheits- bzw. Abstraktionsebenen Löcher: Lücken in Maßnahmen und Fehler im Design Löcher wandern und ändern Größe Fault -> durch alle Löcher -> Failure

Ursachenbekämpfung Kapselung Built-in self-test nicht ausreichend Komplexitätsverteilung Interfaces! Excessive Testing Schwer möglich Built-in self-test nicht ausreichend Coverage

Dokumentation Sehr wichtig Errata Schreiben Lesen Sehr wichtig, da Vermeidung falscher Annahmen Errata Bekannte Fehler des Chipentwicklers Workarounds

Errata Designfehler Herstellungsfehler Intel FDIV Fehler Hersteller kann auf Komponentenprobleme hinweisen Workaround Intel FDIV Fehler

Microcode Aufteilung von Assembler-Befehlen in CPU Subbefehle Zu Ausführungszeit noch änderbar Gezielte Beeinflussung der Löcher im Swiss Cheese Modell Kann über BIOS oder Betriebssystem beeinflusst werden Änderung des Microcodes ohne Assembler Code zu verändern Bsp. Linux AMD Microcode

Race Conditions Multithreading/Multiprocessing Interrupts Treten meist beim Testen nicht auf, schwer auffindbar

Beispiel Drei redundante Systeme, kugelgesichert Aluminium Box Horizontale Motherboards Vertikale Leiterplatten Was könnte passieren? Quelle [7]

Beispiel Drei redundante Systeme, kugelgesichert Aluminium Box Horizontale Motherboards Vertikale Leiterplatten Ein Kondensator in der untersten Box explodiert Quelle [7]

Beispiel Drei redundante Systeme, kugelgesichert Aluminium Box Horizontale Motherboards Vertikale Leiterplatten Ein Kondensator in der untersten Box explodiert Splitter schießen nach oben und zerstören die anderen beiden Systeme Quelle [7]

Multi-chip Modul Quelle [7]

„verfluchtes“ Flugmanöver Ansteigende Rechtskurve Stärker als 3G Etwas Seitenlage Höher als 3000 m Keine Anzeichen warum der Fehler auftrat Lösung: nur unter diesen Bedingungen nähert sich ein loses Kabel an Spannungsversorgung und sorgt für einen Spannungsüberschlag (18 kV) Quelle [7]

Verteiltes Prozessorsystem Spannungskonverter versagt -> Überspannung Datenbus wird durch Überspannung in Dauerbetrieb versetzt Das System war so designt, dass für jeden Datenbus ein eigener Treiber pro Prozessor vorhanden war und Treiberausfälle unabhängig voneinander sind (Annahme!) Alle Treiber waren gleichzeitig betroffen Alle Datenbusse wurden gestaut System war als Flug Kontroll System geplant mit 10^-9 Fehlerwahrscheinlichkeit Quelle [7]

„Stuck At“ Fehler Quelle [7]

„Stuck At“ Fehler Quelle [7]

Input -> Output Quelle [7]

Frequency Divider Quelle [7]

„verflüchtigende“ Software Quelle [7]

Errata lesen DMA Sequenz a, b, c, d, e, f, g, … Quelle [7]

„Komplett“ getestete Software A und C sind exzessiv getestet B nicht Das System hatte keine Timing Probleme B funktionierte nicht mehr richtig nach kleiner Änderung von A Welche Routine funktionierte nicht mehr richtig? Routine C Quelle [7]

Conclusio Immer misstrauisch sein Je mehr Annahmen desto verwundbarer Erfahrung Welche unkonventionellen Fehler kennen Sie?

Quellverzeichnis [1] Google Suche nach „unkonventionell Bedeutung“, https://www.google.at/?gws_rd=ssl#safe=off&q=unkonventionell [2] Murphy Was an Optimist, Präsentation von Kevin R. Driscoll, http://www.rvs.uni-bielefeld.de/publications/DriscollMurphyv19.pdf [3] Federal Aviation Administration „Lessons Learned Fom Transport Airplane Accidents“, http://lessonslearned.faa.gov/index.cfm 10.12.2016 [4] John Rushby‘s Anomalies in Digital Flight Control Systems [5] Safety-critical email list archives, http://www.systemsafetylist.org/ [6] Wikipedia, https://en.wikipedia.org/wiki/List_of_software_bugs

Quellverzeichnis 2 [7] List of Scenarios Honeywell, https://c3.nasa.gov/dashlink/static/media/other/ObservedFailures5.htm l, 10.12.2016 [8] Kevin Driscoll, Brendan Hall, Håkan Sivencrona, Phil Zumsteg; Byzantine Fault Tolerance, from Theory to Reality [9] Prof James Reason's Swiss Cheese Model, https://www.youtube.com/watch?v=twsA3z3xFVE, 10.12.2016