OSDay 19 oder warum die C-Sprache noch lebt

Kürzlich (10.-11. Juni) fand in Moskau die nächste wissenschaftlich-praktische OSDay -Konferenz statt. Diesmal fand die Konferenz im Mathematischen Institut statt. V.A. Steklov RAS. Formal war es Entwicklungswerkzeugen für Betriebssysteme und Systemsoftware gewidmet. Wie üblich beschränkten sich die auf der Konferenz behandelten Themen nicht nur auf formelle Fragen, sondern die aufgeworfenen Fragen wurden aus verschiedenen Blickwinkeln betrachtet und verschiedene Lösungsansätze erörtert. Unterschiedliche Ansichten und Ansätze - das ist meiner Meinung nach das, was die Konferenz von den anderen unterscheidet. So provozierte beispielsweise Dmitry Zavalishin ( Dzavalishin ), einer der Organisatoren, am Ende des zweiten Konferenztages, buchstäblich am Ende des Vorhangs, eine hitzige Diskussion darüber, dass die Programmiersprache C tatsächlich veraltet sei und entwickelt werden müsse (einschließlich Betriebssystemen). Zumindest in speicherverwalteten Sprachen. Ich werde meine Vision dieser Diskussion und anderer interessanter Themen vorstellen, die ich auf der Konferenz in diesem Artikel angesprochen habe. An wen es interessant ist frage ich unter kat.

Ausstellung

Ich werde nicht mit einer Überprüfung der Berichte beginnen, sondern mit der Ausstellung, die Teil der Konferenz ist. Mehrere Unternehmen haben ihre Entwicklung im Bereich der Systemsoftware gezeigt. Dies sind hauptsächlich Betriebssysteme, aber zum Beispiel hat das Unternehmen RED SOFT neben dem Betriebssystem die DBMS-Datenbank „RED Database“ eingeführt, die auf dem Projekt „Firebird“ basiert. Ich habe dieses DBMS bereits bei der Überprüfung einer der vorherigen OSDay-Konferenzen erwähnt . Neue Informationen für mich waren, dass es auf die Elbrus-Architektur portiert wurde.

Die Unterstützung der Elbrus-Architektur wurde in Produkten anderer Aussteller angekündigt. Die Informationen, die das Alt-Linux-Betriebssystem auf Elbrus-Prozessoren ausführt, wurden für mich natürlich nicht neu. Die Mitarbeiter von Basalt-SPO brachten wie üblich einen Stand auf Basis von Elbrus und demonstrierten die Funktionsweise ihres Betriebssystems auf dieser Plattform. Die Tatsache, dass das QP-OS-Banner, über das ich auch mehrmals in den Konferenzberichten gesprochen habe , die Unterstützung für Elbrus-Prozessoren beanspruchte, überraschte mich. Schließlich haben wir große Anstrengungen unternommen, um Embox auf diese Architektur zu portieren, über die wir auch auf dem Hub geschrieben haben Es stellte sich heraus, dass dies leider kein vollwertiger Port für die e2k-Architektur ist. Der Start erfolgte im x86-Befehlsübersetzungsmodus, der, wie Sie wissen, in Elbrus-Prozessoren vorhanden ist.

Die Unterstützung verschiedener Hardwareplattformen war ein Merkmal aller Aussteller (mit Ausnahme von RusBITech-Astra, aber sie haben, wie Sie wissen, ihre eigene Nische). RED SOFT zeigte sein RED OS (wenn ich es richtig verstanden habe, ist dies der Nachfolger von GosLinux, das in der inländischen Softwareregistrierung aufgeführt ist) auf RaPi. QP OS hat die Unterstützung für ARM erklärt. Alt Linux war jedoch bei weitem die plattformübergreifendste. Die Kollegen zeigten nicht nur Arbeiten im heimischen Elbrus und im Baikalsee, sondern beispielsweise auch an einer relativ seltenen Architektur wie RISC-V .

Informationssicherheit

Das Thema Software-Sicherheit ist sehr weit gefasst. Auf der Konferenz wurde mehrmals erklärt, dass es verschiedene Arten von Sicherheit gibt, genauer gesagt, was Sicherheit ist. Sie kommen aus englischer Sicherheit, Zuverlässigkeit und so weiter. Daher sprach der Redner normalerweise darüber, um welche Art von Sicherheit es sich im Moment handelt. Obwohl sich alle einig waren, dass es schwierig ist, über Informationssicherheit (Sicherheit) zu sprechen, wenn die funktionale Sicherheit (Sicherheit) nicht gewährleistet ist.

Die Konvention der Aufteilung in Sicherheit - Sicherheit war im Abschnitt über Informationssicherheit deutlich sichtbar. Zum Beispiel präsentierte Alexander Popov ( a13xp0p0v ), ein Linux-Kernel-Entwickler, der auf einer früheren Konferenz eine Präsentation zum Thema „Wie STACKLEAK die Sicherheit von Linux-Kerneln verbessert“ hielt, die „Karte der Sicherheitsfunktionen für Linux-Kernel“. Die Karte zeigt, dass der Schlüssel zur Informationssicherheit darin liegt Bereiche der Qualitätssoftware. Schließlich sind die meisten Sicherheitsprobleme Standard: Pufferüberläufe, Stapelüberläufe, Löschen des Stapels bei Rückkehr von einem Systemaufruf usw. Sie können sein Projekt auf Github anzeigen . Gestern auf einem habr veröffentlicht

Das Problem der Unbestimmtheit des Konzepts der Software-Sicherheit wurde auch in einem Bericht von Ekaterina Rudina vom Kaspersky Lab aufgezeigt: „Das Modell der Reife der Sicherheit des Internet der Dinge zur Festlegung, Koordinierung und Begrenzung der Anforderungen an Betriebssysteme“. Aus dem Bericht ging hervor, dass das Sicherheitskonzept variieren kann, wenn es auf verschiedene Bereiche und sogar auf verschiedene Arten von Geräten und Produkten angewendet wird. Was offensichtlich ist, warum zum Beispiel ein Antivirenprogramm auf Ihrem Fitnessarmband. Daher schlug das Industrial Internet Consortium , zu dem auch Kaspersky Lab gehört, vor, das IoT-Sicherheitsreifegradmodell (IoT SMM) zu verwenden, um das Sicherheitskonzept für einen bestimmten Fall zu formulieren.

Ich denke, aufgrund der schwierigen Trennbarkeit von Sicherheit und Schutz gab es nicht sehr viele Berichte über reine Informationssicherheit. Ein anschauliches Beispiel für eine solche Rede war ein Bericht des OpenSSL-Committers Dmitry Belyavsky, „Software-Hosting: Ein Ansatz aus der Welt von Open Source“. In dem der Autor über die Schwierigkeiten bei der Unterstützung nationaler Kryptografiestandards sprach.

Funktionssicherheit

Funktionale Sicherheit (Sicherheitssoftware) in der einen oder anderen Form war in fast allen Berichten der Konferenz vorhanden. Wenn Sie genauer hinschauen, selbst in der bereits erwähnten Diskussion über die Veralterung der C-Sprache, wurde schließlich verstanden, dass diese Sprache unsicher ist und es mit ihrer Hilfe sehr einfach ist, sich selbst in den Fuß zu schießen.

Den Berichten auf der Konferenz nach zu urteilen, wird die Verbesserung der funktionalen Sicherheit (Zuverlässigkeit) von Software für die Teilnehmer in der Verwendung von Tools gesehen. Vielleicht ist dies jedoch eine Hommage an das erklärte Thema der Konferenz - Tools. Daher schlug die überwiegende Mehrheit der Berichte genau einen instrumentellen Ansatz vor. Einer der Organisatoren der Konferenz ISP RAS ist auf die Entwicklung von Tools für die statische und dynamische Code-Analyse spezialisiert. Tatsächlich gab ISP RAS mit einer Rede von Alexander Gerasimov mit einem Bericht „Verwenden automatischer Programmanalysetools im sicheren Softwareentwicklungszyklus“ den Ton an.

Zum Thema der Entwicklung statischer Analysegeräte gab es einen Bericht von Vladimir Kozyrev vom Unternehmen Advalange „Entwicklung von Tools zum Sammeln und Analysieren der Abdeckung von Bordsoftware“. Das vorgestellte Toolkit wurde zum Überprüfen der On-Board-Software gemäß dem DO-178C-Standard entwickelt. Das gleiche Toolkit kann jedoch nicht nur in On-Board-Software verwendet werden, da der analysierte Code für die Abdeckung normal ist.

Neben Berichten über die Entwicklung von Werkzeugen gab es mehrere Berichte über die Erfahrungen mit der Verwendung ähnlicher (oder derselben) Werkzeuge. In einem Bericht von Pjotr ​​Devyanin von RusBITech- Stra mit dem langen Titel „Erfahrung mit dem Einsatz von Tools zur Erhöhung des Vertrauens in Sicherheitsmechanismen der OSRA Astra Linux Special Edition“ wurde beispielsweise über die Erfahrungen bei der Anwendung dieser Tools auf ein Sicherheitsmodul für ihr Betriebssystem gesprochen.

Natürlich wurden auf der Konferenz nicht nur Softwareanalyse-Tools vorgestellt, sondern auch andere, mit deren Hilfe die Zuverlässigkeit von Software erhöht werden kann. Es war sehr interessant, Dmitry Dagaev mit dem Bericht „Skalierbare Oberon-Technologien als Mittel zur Sicherung sicherer Software für kritische Systeme“ zuzuhören. Der Autor des Berichts ist der Chefdesigner von SCADA QMS für Kernkraftwerke. Erfahrungen aus erster Hand mit Systemen mit „erhöhten Anforderungen an funktionale Sicherheit und Schutz vor Cyber-Bedrohungen“ (Zitat aus der Anmerkung zu seinem Bericht). Um die Software-Sicherheit zu erhöhen, schlägt der Autor die Verwendung der Oberon- Technologie vor. Der Autor der Sprache Oberon, Nikolaus Wirth , brachte die Idee auf, Einschränkungen einzuführen, die das Risiko des Schreibens unsicherer Software erheblich verringern. Gleichzeitig schlägt der Autor des Berichts mit Hilfe der Verfeinerung des Compilers vor, Bilder für verschiedene Aufgaben und Plattformen zu erstellen. Der Bericht war mir sehr nahe, da wir bei Embox ähnliche Ideen zu Einschränkungen hatten. Sie schlugen jedoch vor, Einschränkungen unter Verwendung der Modulbeschreibungssprache einzuführen (eine deklarative Sprache der eigenen Komposition, die auf eine bestimmte Aufgabe abzielt). Um Artefakte zu generieren, mit denen Sie Bilder für eine bestimmte Aufgabe erstellen können, ist es unserer Meinung nach auch einfacher, eine separate Sprache zur Beschreibung dieser Artefakte zu verwenden.

Infolgedessen berichteten die Konferenzorganisatoren in einem Abschnitt über verschiedene Ansätze zur Sicherung von Software, vor allem zur funktionalen Sicherheit. Der erste Ansatz besteht darin, Werkzeuge für die Codeanalyse zu verwenden, der zweite darin, Sprachen auf höherer Ebene zu verwenden, und schließlich der Ansatz des Kaspersky Lab, der eher organisatorisch oder methodisch ist. Es gab auch einen Bericht über den Debugger, aber ich sollte ihn besser in einen separaten Abschnitt einfügen, obwohl das Debuggen natürlich die Anzahl der Fehler verringern und daher auch die Zuverlässigkeit der Software erhöhen kann.

Debugging-Tools

Auf der Konferenz wurden verschiedene Tools zum Debuggen und Profilieren von Systemsoftware vorgestellt.
Valery Egorov von der Firma NTP „Cryptosoft“ (Entwickler des QP-Betriebssystems ) sprach über den PathFinder-Debugger, der in ihrem QP-VMM-Hypervisor verwendet wird. Natürlich ganz für sich, mit allen sich daraus ergebenden Vor- und Nachteilen.

Denis Silakov , Senior Systemarchitekt , Virtuozzo
Er sprach über die Erfahrung, Fehler basierend auf dem ABRT (Automatic Bug Reporting Tool) zu finden. Erstellen Sie ein Protokoll von allem, was für die Analyse nützlich sein kann, senden Sie einen Bericht im Notfall an den Server und analysieren Sie ihn bereits auf dem Server.

Fedor Chemerev von NIISI RAS sprach über Rückverfolgungsmöglichkeiten im Betriebssystem des Wohnmobils der Baget-Familie. Da sich das Baget RTOS auch bei Virtuozzo auf eingebettete Systeme konzentriert, werden Informationen auf der Instrumentenmaschine gesammelt und die Analyse auf dem Server durchgeführt. Informationen werden durch Schreiben in das Ereignisprotokoll gesammelt, während das Protokoll ohne Notfallsituationen analysiert werden kann.

Modularer Ansatz

Der erste Vortrag über Tools, die die Modularität von Software und die Vorteile der Modularität fördern, war der bereits erwähnte Vortrag über die Oberon-Technologie .

Darüber hinaus gab es drei weitere Berichte, von denen jeder einen eigenen Ansatz für das Problem der Gewährleistung der Modularität vorschlug. Dmitry Alekseev von Eremex LLC präsentierte den Bericht „Abhängigkeitsinjektion in komponentenorientierter Software unter C / C ++“. Darin sprach der Autor über das Umschalten der Konfiguration verschiedener Module des Kernels des FX-RTOS-Betriebssystems sowie verschiedener Schnittstellen. Ein makrobasiertes Projekt wurde implementiert. Lesen Sie mehr im Artikel über Habr .

Ich, Anton Bondarev , als Teilnehmer am Embox-Projekt, präsentierte einen Bericht „Erfahrung in der Entwicklung und Verwendung eines Assemblersystems auf der Basis einer speziellen Programmiersprache“, in dem ich über unsere Erfahrungen bei der Entwicklung der Mybuild-Sprache sprach, die teilweise auf dem Hub geschrieben wurde . In unserem Fall wird die Modularität und Implementierung von Abhängigkeiten mithilfe separater Dateien bereitgestellt, die Module in einer deklarativen Sprache beschreiben.

Und der dritte ist ein Bericht von Mullachiev Kurbanmagomed vom ISP RAS „Über die Verwendung eines modularen Ansatzes in eingebetteten Betriebssystemen“. Dieses Tool wurde in einem anderen JetOS-Betriebssystem verwendet. Zur Beschreibung der Module wird die YAML-Sprache verwendet. Leider wurden keine Beispiele angegeben, aber die geäußerte Idee war sehr interessant und wir berücksichtigen sie in unserem Projekt. Die Idee ist, eine Schnittstelle zu exportieren (zu deklarieren) und Objekte können über diese Schnittstelle verbunden werden. Es wurde die Idee geäußert, dass die Autoren IDL neu erfanden. Dies ist aber sicherlich nicht der Fall, nur enge Ideen.

Eine solche Anzahl von Berichten über einen modularen oder Komponentenansatz zeigt wahrscheinlich die Bedeutung des Komponentenmodells für die Erstellung zuverlässiger Software. Schließlich zweifelt niemand daran, dass ein modularer Ansatz die Komplexität von Software und damit ihre Zuverlässigkeit verringern kann. dass die richtige Struktur (Architektur) der Software erstaunliche Ergebnisse liefert; dass die richtige API (im Wesentlichen ein Softwarevertrag) die Software besser unterstützt. Es ist jedoch einfacher zu sagen, dass Sie die richtige Schnittstelle erstellen müssen, als sie zu implementieren. In einem Bericht über Oberon wird beispielsweise die Verwendung zustandsloser Module vorgeschlagen. Das löst natürlich das Problem, aber ich persönlich habe noch nie ein echtes System gesehen, das keinen Zustand hat.

Zurück zur Diskussion über veraltete C.

Die Probleme bei der Verwendung der C-Sprache liegen auf der Hand. Daher werden alle Arten von Lösungsmöglichkeiten verwendet, statische Analysegeräte, verschiedene Arten von Tests und vieles mehr. Es stellt sich eine vernünftige Frage: Warum so viel Aufwand betreiben?
Da die Diskussion offen war und allen ein Mikrofon zur Verfügung gestellt wurde, war klar, dass einige der Konferenzteilnehmer diese Idee voll und ganz unterstützten, und einige äußerten verschiedene Zweifel daran, dass die C-Sprache zumindest im Bereich der Systemprogrammierung in naher Zukunft der Vergangenheit angehören würde.

Zunächst werde ich die Argumente des Teils der Teilnehmer nennen, der die Idee unterstützt hat. Offensichtlich wurde die Idee von Dmitry Dagaev, dem Autor des Berichts über Oberon, unterstützt. Als Argument zitierte er ein Foto, auf dem er auf dem Bild mit Nikolaus Wirth ein Plakat mit der Aufschrift hält, dass Sie nur auf Oberon Programmieren unterrichten müssen. Andere Diskussionsteilnehmer stellten die These auf, dass die von Neumann-Architektur etwas veraltet sei. Zumindest können Sie markierten Speicher wie in der Elbrus-Architektur verwenden. Und es ging nicht um Elbrus-Architektur, sondern um moderne Trends in der ARM-Architektur, und Alexander Popov, der bereits erwähnt wurde, sagte dies. Natürlich gab es sofort diejenigen, die ein Betriebssystem schreiben wollten, von dem einige Funktionen in Hardware implementiert werden. Eine ganze Reihe von Teilnehmern, die das Thema der Verwendung einer anderen Sprache entwickelten, schlug natürlich die Verwendung funktionaler Programmiersprachen vor. Bei der Entwicklung des Themas Sprache kamen wir zu dem Schluss, dass es in unserem Land keine zertifizierten Entwicklungstools gibt, z. B. einen Compiler für ARM, und dass Compiler, die verwendet werden dürfen, möglicherweise Lesezeichen enthalten. Daher ist es offensichtlich, dass Sie zuerst einen Compiler erstellen und erst dann darauf basierende Software einschließlich der Betriebssysteme schreiben müssen.

Die Argumente des zweiten Teils der Diskussionsteilnehmer sprachen sich weniger für die Verwendung der C-Sprache aus, sondern erklärten vielmehr, warum diese Sprache immer noch der Standard für die Erstellung von Betriebssystemkernen ist. Solche Argumente klangen. Die Syntax der C-Sprache impliziert eine vollständige und explizite Kontrolle aller Programmelemente durch den Programmierer, einschließlich der Speicherzuweisung, mit der Sie sehr ressourceneffiziente Algorithmen erstellen können. Die C-Sprache wird in der Tat von Entwicklungswerkzeugen unterstützt, z. B. gcc. Die Syntax der Sprache ist sehr einfach und einer sehr großen Anzahl von Menschen vertraut.

Die Allegorie mit Raumschiffen und alten Straßen hat mir sehr gut gefallen. Ausgehend davon werden jetzt gewöhnliche Autos verwendet, die wahrscheinlich nicht sehr gut sind, die Umwelt verschmutzen und eine hohe Unfallrate haben. Aber um auf einige unbemannte Supersportwagen umzusteigen, müssen Sie wahrscheinlich erwachsen werden, ein Straßennetz von angemessener Qualität aufbauen, tanken, Algorithmen entwickeln und so weiter. Die Arbeiten in diesen Bereichen sind im Gange, aber es ist unwahrscheinlich, dass solche alten Autos genommen und verboten werden.

Ich stimme absolut zu, Sie müssen zuerst die Industrie entwickeln und Spezialisten ausbilden, und dies sind sehr lange Prozesse. Jetzt müssen Sie eine Reihe bereits entwickelter Software in C verwenden, da diese viel zuverlässiger und debuggerter ist als die neu erstellte, wenn auch mit fortschrittlichen Technologien. In der Tat, obwohl nicht bei dieser Diskussion, ertönten solche Warnungen auf der Konferenz. Der Autor des Hosting-Berichts für kryptografische Software, Dmitry Belyavsky, antwortete beispielsweise auf die Frage, was der Sicherheitsentwickler wissen muss: "Schreiben Sie niemals selbst Kryptografie." Und Dmitry Shevtsov von FSTEC bat mich, mich mehr um die Unterstützung der entwickelten Software zu kümmern.

Bei Schulungsspezialisten ist dies wahrscheinlich die wichtigste Frage: Was „denken“ Experten? Die Software wird daraufhin entwickelt. Es ist durchaus möglich, dass die C-Sprache zum De-facto-Standard für das Betriebssystem wurde, da sie UNIX und Minix enthielt (und vielleicht deshalb) das war für die UNIX-Entwicklung konzipiert). Daher kann das Projekt, Schülern und Schülern das Programmieren in der Sprache der Oberon- Informatik 21 beizubringen, Früchte tragen, es muss jedoch viel Zeit vergehen.

Fazit

Wie ich in der Einleitung sagte, können Sie auf dieser Konferenz Ideen austauschen, diskutieren und diskutieren. Zu vielen Themen wurden verschiedene Ansätze vorgestellt, beispielsweise zu modularer Software und sicherer Software. Darüber hinaus rufen die Organisatoren der Konferenz wissentlich Redner mit unterschiedlichen Ansätzen an, was die Konferenz noch interessanter macht. Und natürlich ist die Konferenz sehr offen, wie Dmitry Zavalishin während der Diskussion über die C-Sprache sagte: „Fünf Minuten Ruhm für alle.“

PS

Ich habe gerade einen Artikel über einen Hub namens "Technische Medien als Basar" gelesen.Es erklärt, wie wichtig es ist, verschiedene Meinungen zu haben. Ich schlage vor, die Diskussion über die C-Sprache auf Habré fortzusetzen. Zum Beispiel ist es sehr interessant zu wissen, ob es plattformübergreifende Industrielösungen für Rost oder Go gibt?