OSDay 19 or why is the C language still alive?

Recently (June 10-11), another OSDay research and practice conference was held in Moscow. This time the conference was held at the Mathematical Institute. V.A. Steklov RAS. Formally, it was devoted to tools for developing operating platforms and system software. As usual, the topics covered at the conference were not limited to the formally stated ones, and the issues raised were examined from various perspectives and various approaches to their solution were discussed. Different views and approaches are, in my opinion, what distinguishes the conference from the rest. So, for example, at the end of the second day of the conference, literally at the end of the curtain, Dmitry Zavalishin ( dzavalishin ), one of the organizers, provoked a heated discussion that the C programming language is generally outdated and it is necessary to develop (including operating systems) at least in languages ​​with controlled memory. I will set forth my vision of this discussion and other topics that are interesting to me at this conference. Who cares please under the cat.

Exhibition

I will begin not with a review of reports, but with an exhibition that is part of the conference. Several companies have shown their development in the field of system software. These are mainly operating systems, but, for example, the company RED SOFT, in addition to the OS, introduced the DBMS “RED Database” based on the “Firebird” project . I have already mentioned this DBMS when reviewing one of the past OSDay conferences . New information for me is that it is ported to the architecture of Elbrus .

Support for the architecture of Elbrus was announced in the products and other exhibitors. Information that Alt-Linux OS is executed on Elbrus processors, of course, did not become news to me. Employees of Basalt-SPO, as usual, brought a stand at the base of Elbrus and demonstrated the work of their operating system on this platform. But the fact that on the QP OS banner, about which I also several times already told in the reviews of the conference , the support of the Elbrus processors is declared, surprised me. After all, we made a lot of effort to port Embox to this architecture, which was also written on Habré . It turned out that unfortunately, this is not a full-fledged port for e2k architecture, the launch was carried out in the x86 command translation mode, which, as is known, is present in Elbrus processors.
')
Support for various hardware platforms was a chip for all exhibitors (with the exception of RusBITech-Astra, but they, as you know, have their own niche). RED SOFT showed its RED OS (if I understood correctly, this is the heir of GosLinux, which is included in the register of domestic software) on RaPi. The QP OS has declared support for ARM. But of course, Alt-Linux was the most cross-platform. Colleagues showed work not only on domestic Elbrus and Baikal, but also, for example, on such a relatively rare architecture like RISC-V .

Information Security

The topic of security software is very broad. At the conference, several times they explained that there are several different types of security, more precisely, definitions of what security is. They come from the English safety, security, reliability, and so on. Therefore, the speaker usually spoke about what kind of security is being discussed at the moment. Although everyone agreed that it is difficult to talk about information security (security) if functional safety (safety) is not ensured.

The convention of separating into security - safety was clearly visible in the section on information security. For example, Alexander Popov ( a13xp0p0v ), the developer of the Linux kernel, who spoke at the previous conference on “How STACKLEAK improves the security of the Linux kernel”, presented the report “The Linux kernel protection card”, and the map shows that the key to information security lies in quality software areas. After all, most security problems are standard: buffer overflow, stack overflow, not clearing the stack when returning from a system call, etc. You can view its project on github . Yesterday published on Habré .

The problem of blurring the concept of software security was also demonstrated in a report by Ekaterina Rudina from Kaspersky Lab, “The security maturity model of the Internet of things to establish, coordinate and limit requirements for operating systems.” From the report it followed that the concept of security may differ in application to different areas, and even to different types of devices and products. What is obvious, well, why, for example, on your fitness bracelet antivirus. Therefore, in the Industrial Internet Consortium , in which Kaspersky Lab is a member, they suggested using the IoT Security Maturity Model (IoT SMM) security maturity model to formulate the concept of security for a particular case.

I think that because of the difficult separability of security and safety, there were not very many reports on pure information security. A vivid example of such a speech was the report from the OpenSSL committee-editor Dmitry Belyavsky “Software Hosting: an Approach from the World of Open Source”. In which the author told about the difficulties of supporting national standards for cryptography.

Functional safety

Functional safety (safety software) in one form or another was present in almost all reports at the conference. After all, if you look deeper, even in the already mentioned discussion about the obsolescence of the C language, it was assumed that this language is not safe and with its help it is very easy to "shoot yourself in the foot."

Judging by the reports at the conference, the participants see an improvement in the functional safety (reliability) of the software in the use of tools. Although, perhaps, this is a tribute to the stated topic of the conference - tools. Therefore, the overwhelming majority of reports offered precisely the instrumental approach. One of the organizers of the ISP RAS conference specializes in developing tools for static and dynamic code analysis. Actually, ISP RAS set the tone with a speech by Alexander Gerasimov with the report “The use of automatic software analysis tools in the software development cycle”.

On the subject of the development of static analyzers, there was a report from Vladimir Kozyrev from Advalange company “Development of tools for collecting and analyzing on-board software coverage”. The presented toolkit was developed for the verification of on-board software according to the DO-178C standard , but the same toolkit can be used not only in on-board software, because the analyzed code to cover is ordinary C.

In addition to the reports on the development of tools, there were several reports on the experience of using similar (or the same) tools. For example, a report by Peter Devianin from RusBYTech -Astra with a long title “Experience of using tools to increase confidence in the security mechanisms of OSSN Astra Linux Special Edition” told about the experience of applying these tools to the security module for their OS.

Naturally, not only software analysis tools were presented at the conference, but also others that could be used to increase software reliability. It was very interesting to listen to Dmitry Dagayev with the report “Scalable Oberon Technologies as a Means of Ensuring Protected Software of Critical Systems”. The author of the report is the chief designer of SCADA SUOK for nuclear power plants. Therefore, I had first-hand experience of systems with “increased requirements in terms of functional security and protection against cyber threats” (quotation from the annotation to his report). To increase the security of the software, the author suggests using Oberon technology. The author of the language Oberon, Nikolaus Wirth , put the idea of ​​introducing restrictions, which significantly reduces the risk of writing unsafe software. At the same time, using the compiler's revision, the author of the report proposes to create images aimed at different tasks and platforms. The report was very close to me, because we at Embox came up with similar ideas on restrictions. But they suggested restrictions to be introduced using the language of module descriptions (the declarative language of one’s own composition aimed at a specific task). And to generate artifacts that allow you to create images for a specific task, in our opinion, it is also easier to use a separate language to describe these artifacts.

As a result, the conference organizers brought together reports on various approaches to secure software in one section, primarily on functional security. The first approach is to use tools for code analysis, the second is to use higher-level languages ​​and, finally, the approach of Kaspersky Lab, which is more organizational or methodical. There was another report about the debugger, but I'd rather take it to a separate section, although, of course, debugging reduces the number of errors and, therefore, also increases the reliability of the software.

Debugging Tools

Several tools for debugging and profiling system software were presented at the conference.
Valery Egorov from CryptoSoft NTP (the creator of the QP OS ) spoke about the PathFinder debugger, which is used in their QP VMM hypervisor. Naturally, all his own, with all the attendant advantages and disadvantages.

Denis Silakov , Senior Systems Architect, Virtuozzo
He told about the experience of finding errors based on the ABRT (Automatic Bug Reporting Tool). Building a log of everything that can be useful for analysis, sending a report when an emergency situation occurs on the server, and further analysis is already on the server.

Fyodor Chemerev from the NIISI RAS told about tracing tools in the RV OS of the “Baguette” family. Since the “Baguette” RTOS is focused on embedded systems, even in the case of Virtuozzo, information is collected on the instrumental machine, and analysis takes place on the server. Information is collected by writing to the event log, and the log can be analyzed without emergency situations.

Modular approach

The first report about the toolkit that promotes software modularity and the benefits of modularity was the already mentioned report about Oberon technology .

In addition, there were still three reports, each of which offered its own approach to the problem of ensuring modularity. Dmitry Alekseev from Eremex LLC presented the report “Implementing dependencies in component-oriented C / C ++ software”. In it, the author told about switching the configuration of various modules of the FX-RTOS OS kernel and also various interfaces. Implemented a project based on macros. More in the article on Habré .

I, Anton Bondarev , as a member of the Embox project, presented the report “Experience in developing and using an assembly system based on a specialized programming language,” in which he spoke about our experience in developing the Mybuild language, which was partially written in Habré . In our case, modularity and dependency injection is provided by separate files, in which modules are described in a declarative language.

And the third is a report from Mallachiyev Kurbanmagomed from ISP RAS “On the use of a modular approach in embedded operating systems”. This tool was used in another JetOS OS. For the description of the modules used language YAML. Unfortunately, no examples were given, but the voiced idea was very interesting and we are considering it in our project. The idea is to export (declare) an interface and objects can be connected through this interface. The idea was voiced that the authors re-invented IDL . But this is certainly not the case, just close ideas.

Such a number of reports on the modular or component approach probably indicates the importance of the component model for creating reliable software. After all, no one doubts that a modular approach can reduce the complexity of the software, and hence its reliability; that the correct structure (architecture) of the software gives amazing results; that the correct API (essentially a software contract) makes the software more supported. But it's easier to say that you need to make the right interface than to implement it. For example, the Oberon report suggests using stateless modules. Naturally, this solves the problem, but personally I have never seen a real system that would not have a state.

Returning to the discussion on obsolete C

The problems of using C are obvious, therefore, various methods of solving them are used, and static analyzers, and various types of testing, and much more. A reasonable question arises: why spend so much effort?
Since the discussion was open and a microphone was provided to everyone, it was clearly visible that some of the conference participants fully supported this idea, and some expressed various kinds of doubts that the C language would be a thing of the past, at least in the field of system programming in the near future.

First, I will cite the arguments of the part of the participants who supported the idea. Obviously, the idea was supported by Dmitry Dagayev, the author of the report about Oberon. As an argument, he cited a photograph where, he is in a picture with Nikolaus Wirth holding a poster with the inscription that it is necessary to teach programming only on Oberon. Other participants in the discussion advanced the thesis that von Neumann's architecture is somewhat outdated, well, at least you can use tagged memory, as in the Elbrus architecture. And it was not about the Elbrus architecture, but about the modern trends of the ARM architecture, and the already mentioned Alexander Popov reported this. Naturally, there were also those who wanted to write an OS, some of the functions of which would be implemented in hardware. Still, a number of participants, while developing the topic of using another language, naturally suggested using functional programming languages. Developing the theme of the language, we came to the conclusion that it turns out that in our country there are no certified development tools, for example, a compiler for ARM, and compilers that are allowed to use may contain bookmarks. Therefore, it is obvious that you first need to create a compiler, and only then write software on its basis, including operating systems.

The arguments of the second part of the discussion participants were not that in favor of using C, they rather explained why this language is still the standard for creating OS kernels. Sounded such arguments. The syntax of the C language implies a complete and explicit control by the programmer of everything in the program, including memory allocation, which allows you to create highly efficient in terms of resources algorithms. The C language is really supported by development tools, for example, take gcc. The syntax of the language is very simple and familiar to a very large number of people.

I really liked the allegory with the spaceships and old roads. On the basis of it, now used conventional machines, which are probably not very good, pollute the environment and have a great accident rate. But in order to go to some unmanned supercars, you probably need to grow to them, build a network of roads of adequate quality, refueling, develop algorithms, and so on. Work in these areas is underway, but in order to pick up and ban old cars like this, this is unlikely to work.

I absolutely agree, first you need to develop the industry and train specialists, and these are very long processes, while you have to use a bunch of already developed software in the C language, since it is much more reliable and more streamlined than the newly created, albeit on advanced technologies. After all, although not in this discussion, similar warnings sounded at the conference. For example, Dmitry Belyavsky, the author of a report on hotel cryptographic software certification, asked what a security developer needed to know, “never write cryptography yourself”. And Dmitry Shevtsov of the FSTEC, asked for more care about the support of the developed software.

Probably, the most important question is about training specialists: what the experts think about is what software will be developed on, it is quite possible that C became the de facto standard for the OS, since it contained UNIX and Minix (or maybe just because that was intended to be developed by UNIX). Therefore, the project of teaching pupils and students to programming in Oberon Informatics 21 can bear fruit, but a lot of time must pass.

Conclusion

As I said in the introduction, this conference allows you to share ideas, discuss and debate. On many issues, several approaches were presented, for example, about modular software and secure software. Moreover, the conference organizers deliberately call speakers with different approaches and this makes the conference even more interesting. And of course, the conference is very open, as Dmitry Zavalishin said during the discussion on the C language, “Five minutes of fame for everyone.”

PS

Just read an article in Habré entitled “Technical Media as a Bazaar” . It explains how important it is to have several different opinions. I propose to continue the discussion on the C language in Habré. For example, it is very interesting to find out if there are any cross-platform industrial solutions for rust or go?