​LabVIEW als speichersichere Sprache

Speichersicherheit bezieht sich auf die Sicherheit, dass ein Programm in einer wohldefinierten, vorhersehbaren Weise auf Speicher zugreift. Diese Funktion verhindert Korruption, Datenlecks und das Schreiben von Daten außerhalb der vorgesehenen Grenzen. Diese Speicherprobleme können zu Abstürzen und undefiniertem Verhalten führen. Schlimmer noch: Bedrohungsakteure manipulieren Speicherprobleme, um beliebigen Programmcode auszuführen, wodurch Speicherfehler in erhebliche Sicherheitslücken umgewandelt werden. Bedenken hinsichtlich der Speichersicherheit umfassen die folgenden Arten von Problemen: 
 

• Pufferüberlauf—Schreiben außerhalb der Grenzen des zugewiesenen Speichers. 
• Dangling Pointers – Zugriff auf bereits freigegebenen Speicher. 
• Use-after-free – Verwendung von Zeigern auf Speicherorte, nachdem diese freigegeben wurden. 
• Speicherlecks – Das Nichtfreigeben von Speicher führt allmählich zu Ressourcenerschöpfung. 

Sprachen, die direkten Speicherzugriff bieten (z. B. durch Zeiger), sind besonders anfällig für diese Probleme. Speichersichere Sprachen dagegen schränken die direkte Speicherverwaltung des Entwicklers ein oder abstrakten sie vollständig ab. 

LabVIEW unterscheidet sich grundsätzlich von herkömmlichen befehlsorientierten Sprachen. Das grafische Programmierprinzip basiert auf Datenflussprinzipien, bei denen die Ausführung von Programmcode durch den Datenfluss zwischen Knoten (Virtuelle Instrumente oder VIs) bestimmt wird.

Folgende Aspekte der LabVIEW-eigenen Architektur fördern die Speichersicherheit:

• Keine direkte Zeigerbearbeitung—LabVIEW stellt dem Entwickler keine Speicheradressen oder Zeiger zur Verfügung.
• Automatische Speicherverwaltung—LabVIEW belegt Variablen, Arrays und Strukturen nach Bedarf mit Speicher.
• Typsicherheit—Die LabVIEW Umgebung erzwingt eine starke Typisierung während der Bearbeitung und Ausführung.
• Unveränderliche Verbindungswerte—Sobald Daten in eine Verbindung eingehen (das grafische Äquivalent einer Variablen), können sie an keiner anderen Stelle im Programm unerwartet geändert werden.
• Referenzzählung und Garbage Collection—LabVIEW verwaltet Datenlebensdauern und stellt sicher, dass Speicher automatisch zurückgefordert wird, wenn er nicht mehr verwendet wird.

Datenflussparadigma und seine Auswirkungen

In LabVIEW werden Programme erstellt, indem Funktionsblöcke mit datenführenden Verbindungen verbunden werden. Jeder Block wird nur ausgeführt, wenn alle erforderlichen Eingabedaten verfügbar sind, und auf Speicherstellen kann nicht zugegriffen werden, bevor die Daten erzeugt wurden, wodurch Laufzeitprobleme im Speicher vermieden werden.

Abbildung 1. LabVIEW Code-Beispiel

Dieses Modell vermeidet natürlich viele Programmierfehler, die durch die unsachgemäße Abfolge von Operationen in zwingenden Sprachen entstehen.

Speicherzuweisung und -verwaltung

Für die gesamte Speicherzuweisung und -verteilung ist die LabVIEW Runtime Engine zuständig. Entwickler müssen niemals manuell Speicher anfordern oder freigeben, wodurch das Risiko von Lecks und Use-after-free-Fehlern vermieden wird. Wenn Arrays oder Cluster (strukturähnliche Daten) wachsen oder schrumpfen, verwaltet LabVIEW den zugehörigen Speicher transparent. Wenn ein Entwickler beispielsweise eine Schleife zum Erstellen eines Arrays erstellt, passt LabVIEW die Größe des Arrays automatisch an und verwaltet den zugehörigen Speicherplatz. Wenn die Array-Variable außerhalb des zulässigen Bereichs liegt, wird der Speicher von LabVIEW zurückgefordert.

Starke Typisierung und Randprüfung

Die LabVIEW Entwicklungsumgebung führt während der Kompilierung und Ausführung von VIs eine gründliche Typprüfung durch. Versuche, inkompatible Datentypen miteinander zu verbinden, werden während der Bearbeitung erkannt, wodurch Laufzeitfehler vermieden werden. Darüber hinaus enthalten Array- und String-Operationen Randprüfungen, um Pufferüberläufe zu verhindern.

Fehlende Low-Level-Speichersteuerung

Einer der wirksamsten Schutzmechanismen ist das Fehlen einer Low-Level-Speichersteuerung: LabVIEW bietet keine Möglichkeit für den Benutzer, eine beliebige Zeigerarithmetik durchzuführen oder direkt auf den Speicher zuzugreifen. Dadurch sind in C oder Assembly übliche Sicherheitslücken wie Stack- oder Heap-Überläufe im systemeigenen LabVIEW Code nicht möglich.

Um die Speichersicherheit von LabVIEW besser zu verstehen, empfiehlt sich der Vergleich mit Programmiersprachen wie C, C++ und sogar Java oder Python.

• C/C++—Diese Sprachen bieten direkten Speicherzugriff, erfordern manuelle Speicherverwaltung und sind für eine Vielzahl von Speichersicherheitsfehlern anfällig. CISA empfiehlt, C/C++ für neue Projekte nicht zu verwenden.
• Java/Python—Diese Sprachen bieten eine automatische Speicherverwaltung, erlauben aber dennoch indirekte Speicherfehler. Viele der zugrunde liegenden Python-Module sind beispielsweise in C geschrieben, und Fehler in diesen Modulen können zu Speicherproblemen in der Python-Anwendung führen. Python erzwingt auch keine Speichersicherheitsregeln während der Ausführung wie andere echte MSLs.
• LabVIEW—LabVIEW liefert keine Zeiger und verwendet strikte Typisierung mit vollständig verwaltetem Speicher, wodurch die Angriffsfläche und das Fehlerrisiko erheblich reduziert werden. LabVIEW ermöglicht es dem Benutzer, in C/C++ geschriebene DLLs aufzurufen, was zu Speicherproblemen führen kann.

Zusammenfassend lässt sich sagen, dass LabVIEW ganze Kategorien von speicherbezogenen Schwachstellen (z. B. Pufferüberläufe) eliminiert und die sichere Entwicklung von Anwendungen vereinfacht, was einen erheblichen Vorteil gegenüber traditionellen Sprachen wie C und C++ bietet und einen ähnlichen Schutz wie Python und Java ermöglicht.

Speichersicherheit in LabVIEW hat für Entwickler, Organisationen und Endnutzer spürbare Vorteile:

• Verringertes Risiko von Sicherheitslücken—Durch das Beseitigen von Pufferüberläufen und Zeigermissbrauch werden viele gängige Angriffsvektoren geschlossen.
• Höhere Zuverlässigkeit—Anwendungen stürzen seltener aufgrund schwer zu findender Speicherfehler ab.
• Schnellere Entwicklung – Entwickler können sich auf die Anwendungslogik konzentrieren, ohne sich um Speicherzuweisungen oder Fehler bei der Verteilung kümmern zu müssen.
• Einfachere Wartung—LabVIEW-Code ist weniger anfällig für subtile Low-Level-Fehler, die die Fehlersuche und Wartung kostspielig und zeitaufwändig machen können.
• Sicherheitskritische Anwendungen—Häufig wird LabVIEW in Umgebungen eingesetzt, in denen Zuverlässigkeit an erster Stelle steht, z. B. in der Laborautomatisierung, industriellen Steuerung und wissenschaftlichen Forschung.

Traditioneller Pufferüberlauf tritt auf, wenn Daten die Grenzen eines Puffers fester Länge überschreiten, wodurch benachbarter Speicher überschrieben wird und möglicherweise willkürlicher Programmcode ausgeführt werden kann. In LabVIEW werden Array- und String-Operationen immer auf Grenzen geprüft. Versuche, über das Ende eines Arrays oder Strings hinaus zu schreiben, führen zu einem Laufzeitfehler und nicht zu einer Speicherbeschädigung.

Wie in jeder speichersicheren Umgebung ist es wichtig, die Grenzen von LabVIEW zu verstehen:

• Externe Code-Integration—Das Aufrufen externer Bibliotheken (DLLs, DLLs) von LabVIEW aus mit dem Knoten zum Aufruf externer Bibliotheken kann zu Speichersicherheitsproblemen führen, wenn diese Bibliotheken nicht selbst sicher sind.
• Ressourcenerschöpfung – Unendliche Schleifen oder unkontrollierte Speicherzuweisungen können zwar zu Speichererschöpfung, aber nicht zu Beschädigung führen.
• Versionskompatibilität—Im Zuge der Weiterentwicklung von LabVIEW können sich bestimmte Verhaltensweisen ändern (z. B. Optimierung der Speicherverwaltung), was beim Aktualisieren oder Portieren von veraltetem Programmcode Aufmerksamkeit erfordert.

Gehen Sie zum Maximieren der Sicherheit beim Aufrufen von externem Programmcode wie folgt vor:

• Unsicheren Code isolieren—Verkapselt unsichere Bibliotheksaufrufe in einem separaten Modul oder Prozess. Verwenden Sie Microservices oder IPC (Interprocess Communication), um speicherunsicheren Code zu isolieren. So kann ein Absturz oder Speicherfehler im unsicheren Programmcode nicht die gesamte Anwendung zu Fall bringen.
• Ein- und Ausgänge gründlich validieren—Speicherfehler entstehen oft durch fehlerhafte Ein- oder Ausgaben. Validieren Sie alle Daten, die an die unsichere Bibliothek gesendet werden. Verwenden Sie Grenzwertprüfungen, Nullprüfungen und Typbestätigungen.
• Statische und dynamische Analysewerkzeuge—Mit Hilfe von Tools können Sie Speicherprobleme frühzeitig erkennen. Testen Sie Speicherprobleme mit den in LabVIEW Professional enthaltenen statischen und dynamischen Speicherwerkzeugen von LabVIEW.
• Unsichere Oberfläche minimieren—Nur den minimal notwendigen Funktionsumfang der unsicheren Bibliothek anzeigen. Komplexe Datenstrukturen oder Zeiger sollten nur weitergegeben werden, wenn dies unbedingt notwendig ist. Halten Sie die Schnittstelle so einfach und klar wie möglich.
• Audit and Monitor—Prüft regelmäßig externen Programmcode, der vom LabVIEW Programm aufgerufen wird. 

LabVIEW basiert auf einem grafischen Datenflussprinzip, einer starken Typprüfung, automatischer Speicherverwaltung und dem Fehlen direkter Zeigerbearbeitung. Entwickler profitieren von reduziertem Risiko von speicherbedingten Fehlern, erhöhter Produktivität und der Möglichkeit, Anwendungen für anspruchsvolle, sicherheitskritische Branchen mit Vertrauen zu erstellen.

Obwohl keine Umgebung vor Fehlern gefeit ist – insbesondere bei der Interaktion mit unsicheren externen Komponenten – legt LabVIEW die Messlatte für die Speichersicherheit gegenüber herkömmlichen befehlsorientierten Sprachen deutlich höher. Für Unternehmen, die Zuverlässigkeit und Sicherheit in Mess-, Automatisierungs- und Steueranwendungen suchen, ist LabVIEW eine überzeugende Wahl für die speichersichere Entwicklung.

• Weitere Informationen zu LabVIEW
• LabVIEW-Editionen im Vergleich
• LabVIEW Demo anfordern