Sicherere Embedded-Systeme - Teil 1
Bessere Codequalität für sichere Systeme
Fortsetzung des Artikels von Teil 1
Wiederverwendung von Komponenten
Sorgfältig entworfen und geschrieben, können diese Komponenten in verschiedenen Anwendungen wiederverwendet werden, wie es bei Bibliotheken oder Plug-ins üblich ist, jedoch mit einem deutlichen Unterschied: Kritische Komponenten in einem sichereren Embedded-System können und sollten in separaten Prozessen ausgeführt werden, um die Sicherheit zu erhöhen.
Die Wiederverwendung von Code wird jedoch auf die Spitze getrieben, wenn Entwickler eine Funktion wiederverwenden oder ändern möchten, sich aber aus Mangel an Wissen oder anderen Gründen davor scheuen. In diesem Fall wird davon abgeraten, dieses Stück Code wiederzuverwenden – nicht einmal in einer Architektur mit Komponententrennung, da es wahrscheinlich effizienter ist, den Code stattdessen von Grund auf neu zu schreiben. Die Wiederverwendung von Code sollte also nicht überschätzt werden. Sorgfältiges Planen und Spezifizieren, welche Softwareelemente benötigt und wiederverwendet werden, steht im Vordergrund.
Natürlich sollten auch hier allgemeine Praktiken der Codewiederverwendung gelten, sodass die Komponenten nicht ausgeschnitten und in ein neues Programm eingefügt werden. Dies ist als Copy-Paste-Programmierung bekannt und sollte vermieden werden. Stattdessen sollte Code für die Wiederverwendung als Komponente in die Gesamtsystemarchitektur eingefügt werden. Auf diese Weise kann derjenige, der die ursprüngliche Komponente verwaltet, weiterhin seinen Codebeitrag als einzelne Instanz kontrollieren.
Der größte Nachteil einer solchen Wiederverwendung ist, dass die Schnittstellen zwischen den Komponenten schwieriger zu ändern sind, da dies mehrere Anwendungen betreffen kann. Dies ist einer der Kompromisse, die man eingehen muss: Um die Qualität der Systeme aufrecht zu erhalten, muss auf Flexibilität zugunsten einer sicheren Implementierung verzichtet werden.
Jobangebote+ passend zum Thema
Codierungsstandards bieten Leitplanken
Jeder Entwickler ist schon mit verschiedenen Arten von Codierungsstandards in Kontakt gekommen, seien es persönliche Codierungsvorlieben, unternehmensinterne Standards oder Industriestandards wie MISRA C oder MISRA C++. Solche Standards sollen Entwickler helfen, gefährliche Codekonstruktionen zu vermeiden, aber auch die Komplexität von Funktionen zu begrenzen und ein einheitliches syntaktisches Aussehen zu etablieren.
Wird ein gemeinsamer Standard vereinbart, kann auf diese Weise Code einfacher durch Kollegen (Peer Code Reviews) überprüft werden. Sie können sich auf den eigentlichen Wert der Überprüfung konzentrieren, nämlich versteckte gefährliche Probleme und Codekonstrukte zu finden, und nicht auf die typischen Komplexitäts- und lexikalischen Überprüfungen, die sonst häufig auftreten. Eine weitere Funktion, die Codierungsstandards bieten, ist eine Möglichkeit, die tatsächlichen Spezifikationen der Programmiersprache zu interpretieren, da diese nicht perfekt sind und viele Fälle von undefiniertem oder implementierungsdefiniertem Verhalten aufweisen können, das nicht mit den Erwartungen oder Absichten der Programmierer übereinstimmt.
Prüfprogramme für Codierungsstandards
Es gibt mehrere Tools, die bei der Codeanalyse helfen: Checker für MISRA und andere Arten von Codierungsstandards stehen zur Verfügung. Mehrere Compiler-Tools implementieren ebenfalls MISRA und andere Arten von Codierungsstandard-Checkern, z. B. der C/C++-Compiler von Green Hills Software.
Ein Überprüfungstool, an das Softwareentwickler jedoch keine Anforderungen stellen, ist der Compiler selbst – auch wenn er keine MISRA-Prüfung durchführt. Ein Compiler kann angewiesen werden, Warnungen für gefährliche oder mehrdeutige Codekonstrukte zu erzeugen. Daher ist es eine gute Praxis für Programmierer, alle Compiler-Warnungen durchzuarbeiten. Dies ist ein einfacher Schritt und eine gute technische Praxis, um sichereren Code zu erstellen.
Als praktische Übung dazu dient das Codebeispiel in Bild 3, das mit dem gängigen GCC-Compiler und mit dem Multi-Compiler von Green Hills Software kompiliert werden kann.
Das Codebeispiel aus Bild 3 zeigt, dass sich beide Compiler unterschiedlich verhalten, wenn es um Warnungen geht. Der Green-Hills-Compiler warnt den Nutzer standardmäßig (Bild 4). Der GCC-Compiler verlangt ausdrücklich, dass die Warnoptionen verwendet werden, um eine Warnung zu erzeugen (Bild 5). Beide Warnungen weisen auf das gleiche Problem hin, beschreiben es aber unterschiedlich und erfordern eine Interpretation.
Im einem zweiten Teil des Beitrags werden die Codeanalyse – statisch und dynamisch – betrachtet, die Bedeutung der Programmiersprache untersucht und typische Programmiertechniken für sichere Embedded-Systeme vorgestellt.
Literatur
[1] McCabe, T. J.: A Complexity Measure. IEEE Transactions on Software Engineering, 1976, H. 4, S. 308–320, DOI: 10.1109/TSE.1976.233837.
[2] Kleidermacher, D. und Kleidermacher, M.: Embedded Systems Security: Practical Methods for Safe and Secure Software. Newnes Elsevier, 2012, ISBN: 978-0-12-386886-2.
Der Autor
Marcus Nissemark
ist seit 2014 als Applikationsingenieur bei Green Hills Software tätig. Bevor er zu Green Hills in Schweden kam, arbeitete Nissemark seit 1999 als Softwarearchitekt und Entwickler von Embedded-Produkten. Zu diesen Produkten gehörten Steuerungen und Anzeigecomputer für schwere Fahrzeuge, medizinische und militärische Geräte. Seine Erfahrung umfasst mehrere Betriebssysteme, die Entwicklung von Gerätetreibern sowie die Herausforderungen des Prozess- und Produktmanagements in der Softwareentwicklung.
marcusn@ghs.com
- Bessere Codequalität für sichere Systeme
- Wiederverwendung von Komponenten
Lesen Sie mehr zum Thema
