OSDay 19 or why C language is still alive

    Recently (June 10-11) the next OSDay scientific and practical conference was held in Moscow . This time the conference was held at the Mathematical Institute. V.A. Steklov RAS. Formally, it was devoted to development tools for operating platforms and system software. As usual, the topics addressed at the conference were not limited to formally stated, and the issues raised were considered from different angles and various approaches to their solution were discussed. Different views and approaches - this, in my opinion, is what distinguishes the conference from the rest. So, for example, at the end of the second day of the conference, literally at the curtain, Dmitry Zavalishin ( dzavalishin), one of the organizers, provoked a heated discussion about the fact that the C programming language is actually out of date and it is necessary to develop (including operating systems), at least, in languages ​​with controlled memory. I will present my vision of this discussion and other topics of interest to me raised at the conference in this article. To whom it is interesting I ask under kat.

    Exhibition


    I will start not with a review of the reports, but with the exhibition, which 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 already mentioned this DBMS during the review of one of the last OSDay conferences . New information for me was that it was ported to Elbrus architecture .

    Support for Elbrus architecture was announced in the products of other exhibitors. The information that the Alt-Linux OS runs on Elbrus processors, of course, did not become news to me. Employees of Basalt-SPO, as usual, brought a stand based on Elbrus and demonstrated the operation of their OS on this platform. But the fact that the QP OS banner, which I also talked about several times in the conference reviews , claimed support for Elbrus processors, surprised me. After all, we put a lot of effort to port Embox on this architecture, which is also written on the Habré . It turned out that, unfortunately, this is not a full port for the e2k architecture, the launch was carried out in the x86 command translation mode, which, as you know, is present in Elbrus processors.

    Support for various hardware platforms was a feature of all exhibitors (with the exception of RusBITech-Astra, but, as you know, they have their own niche). RED SOFT showed its RED OS (if I understood correctly, then this is the successor of GosLinux, which is listed in the domestic software registry) on RaPi. QP OS has declared support for ARM. But by far, Alt Linux was the most cross-platform. Colleagues showed work not only on domestic Elbrus and Baikal, but, for example, on such a relatively rare architecture as RISC-V .

    Information Security


    The topic of software security is very broad. At the conference several times it was explained that there are several different types of security, more precisely definitions of what security is. They come from English safety, security, reliability and so on. Therefore, the speaker usually talked about what kind of security in question 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 dividing into security - safety was clearly visible in the section on information security. For example, Alexander Popov ( a13xp0p0v ), a Linux kernel developer who spoke at a previous conference“How STACKLEAK Improves Linux Kernel Security,” presented the “ Linux Kernel Security Map” report , and the map shows that the key to information security lies in the area of ​​quality software. Indeed, most security problems are standard: buffer overflow, stack overflow, not clearing the stack when returning from a system call, etc. You can view his project on github . Yesterday published on Habré .

    The problem of the vagueness of the concept of software security was also demonstrated in a report by Ekaterina Rudinafrom Kaspersky Lab “The Internet of Things Security Maturity Model for Establishing, Aligning, and Limiting Operating System Requirements”. It followed from the report that the concept of security can vary when applied to different areas, and even to different types of devices and products. What is obvious, well, why, for example, an antivirus on your fitness bracelet. Therefore, the Industrial Internet Consortium , which includes Kaspersky Lab, proposed using the IoT Security Maturity Model (IoT SMM) to formulate the concept of security for a particular case.

    I think, due to the difficult separability of security and safety, there were not very many reports on pure information security. A striking example of such a speech wasreport from OpenSSL committer Dmitry Belyavsky “Software hosting: an approach from the world of Open Source”. In which the author spoke 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 the 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 understood that this language is unsafe and with its help it is very easy to “shoot yourself in the foot”.

    Judging by the reports at the conference, improving the functional safety (reliability) of software for participants is seen in the use of tools. Although, perhaps this is a tribute to the declared theme of the conference - tools. Therefore, the vast majority of reports proposed precisely an instrumental approach. One of the organizers of the conference ISP RAS specializes in the development of tools for static and dynamic code analysis. Actually ISP RAS and set the tone for the speechAlexandra Gerasimova with the report “Application of automatic program analysis tools in the safe software development cycle”.

    On the topic of developing static analyzers, there was a report by Vladimir Kozyrev from Advalange company “Development of tools for collecting and analyzing onboard software coverage”. The presented toolkit was developed for the purpose of verifying 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 for coverage is ordinary C.

    In addition to 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 Devyaninfrom RusBITech-Astra with the long title “Experience with the use of tools to increase confidence in the security mechanisms of the OSRA Astra Linux Special Edition” talked 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, with the help of which it is possible to increase the reliability of software. It was very interesting to listen to Dmitry Dagaev with a report“Scalable Oberon Technologies as Means of Securing Security Software for Critical Systems.” The author of the report is the chief designer of SCADA QMS for nuclear power plants. Therefore, firsthand, I came across systems with “increased requirements in terms of functional safety and protection against cyber threats” (quote from the annotation to his report). To increase software security, 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, with the help of the compiler refinement, the author of the report suggests creating images aimed at various tasks and platforms. The report was very close to me, since we are at Emboxcame up with similar ideas on limitations. But they suggested that restrictions be introduced using the module description language (a 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 summarized in one section reports on various approaches to safe software, and this is primarily about 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 the Kaspersky Lab, which is rather organizational or methodical. There was also a report about the debugger, but I’d better put it in a separate section, although, of course, debugging can reduce the number of errors and, therefore, also increases the reliability of the software.

    Debugging Tools


    The conference presented several tools for debugging and profiling system software.
    Valery Egorov from the company NTP “Cryptosoft” (creator of the QP OS ) spoke about the PathFinder debugger, which is used in their QP VMM hypervisor. Naturally, all their own, with all the ensuing advantages and disadvantages.

    Denis Silakov , Senior Systems Architect, Virtuozzo
    Talked about the ABRT (Automatic Bug Reporting Tool) error search experience. Building a log of everything that may come in handy for analysis, sending a report in case of an emergency to the server, and further analysis already on the server.

    Fedor Chemerevfrom NIISI RAS spoke about tracing facilities in the OS of the RV of the Baguette family. Since the Baget RTOS is oriented to embedded systems, in the case of Virtuozzo, information is also collected on the instrumental machine, and analysis is performed 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 talk about tools that promote software modularity and the benefits of modularity was the already mentioned talk about Oberon technology .

    In addition, there were three more reports, each of which proposed its own approach to the problem of ensuring modularity. Dmitry Alekseev from Eremeks LLC presented the report “Dependency injection in component-oriented software on C / C ++”. In it, the author talked about switching the configuration of various modules of the core of the FX-RTOS OS and also various interfaces. A macro-based project has been implemented. Read more in the article on Habr .

    Me, Anton BondarevAs a participant in the Embox project, he presented the report “Experience in developing and using an assembly system based on a specialized programming language”, in which he talked about our experience in developing the Mybuild language, which was partially written on the hub . In our case, the modularity and implementation of dependencies is provided using separate files, in which modules are described in a declarative language.

    And the third is a report from Mallachiev Kurbanmagomedfrom 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, the YAML language is used. 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 via this interface. The idea was voiced that the authors re-invented the IDL . But this is certainly not the case, just close ideas.

    Such a number of reports on a 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 software complexity, and therefore 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, a report on Oberon suggests using stateless modules. Naturally, this solves the problem, but personally I have never seen a real system that does not have a state.

    Returning to the discussion on obsolete C


    The problems of using the C language are obvious, therefore, all sorts of ways to solve them are used, and static analyzers, and various types of testing, and much more. A reasonable question arises: why spend so much effort?
    As 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 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 give the arguments of the part of the participants that supported the idea. Obviously, the idea was supported by Dmitry Dagaev, author of the report on Oberon. As an argument, he cited a photograph of where, in the picture with Nikolaus Wirth, he holds a poster with the inscription that programming is only needed on Oberon. Other panelists put forward the thesis that von Neumann architecture, is somewhat outdated, well, at least you can use tagged memory, as in the Elbrus architecture. And it was not about Elbrus architecture, but about modern trends in ARM architecture, and Alexander Popov, already mentioned, said this. Naturally, there were immediately those who wanted to write an OS, some of the functions of which will be implemented in hardware. A whole series of participants, 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 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 must first create a compiler, and only then write software based on it, including operating systems.

    The arguments of the second part of the participants in the discussion were not so much in favor of using the C language, rather they explained why this language is still the standard for creating OS kernels. Such arguments sounded. The syntax of the C language implies complete and explicit control by the programmer of everything in the program, including memory allocation, which allows you to create algorithms that are very resource-efficient. C language, indeed, is 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 spaceships and old roads. Proceeding from it, ordinary cars are now used, which are probably not very good, pollute the environment and have a large accident rate. But in order to switch to some unmanned supercars, you probably need to grow up to them, build a network of roads of appropriate quality, refueling, develop algorithms and so on. Work in these areas is underway, but to take and ban old cars like this is unlikely to succeed.

    I absolutely agree, first you need to develop the industry and train specialists, and these are very long processes, for now you have to use a bunch of already developed software in C, since it is much more reliable and more debugged than the newly created, albeit with advanced technologies. After all, although not at this discussion, such warnings sounded at the conference. For example, Dmitry Belyavsky, the author of the cryptographic software hosting report, when asked what security developers need to know, replied, “Never write cryptography yourself.” And Dmitry Shevtsov from FSTEC, asked me to take more care of supporting the developed software.

    About training specialists, it’s probably the most important question: what do experts “think” - the software will be developed on that, it is quite possible that the C language became the de facto standard for the OS, since it had UNIX and Minix (or maybe that’s why that was conceived for UNIX development). Therefore, the project for teaching schoolchildren and students to program in the Oberon Informatics 21 language can bear fruit, however, a lot of time must pass.

    Conclusion


    As I said in the introduction, this conference allows you to share ideas, discuss and discuss. Several approaches were presented on many issues, for example, about modular software and secure software. Moreover, the organizers of the conference knowingly 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 about the C language, “Five minutes of glory to everyone.”

    PS


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

    Also popular now: