OSDay 19 o por qué el lenguaje C sigue vivo

Recientemente (10-11 de junio), la próxima conferencia científico-práctica de OSDay se celebró en Moscú. Esta vez la conferencia se celebró en el Instituto de Matemáticas. V.A. Steklov RAS. Formalmente, se dedicó a herramientas de desarrollo para plataformas operativas y software de sistema. Como de costumbre, los temas tratados en la conferencia no se limitaron a los formalmente establecidos, y los temas planteados se consideraron desde diferentes ángulos y se discutieron varios enfoques para su solución. Diferentes puntos de vista y enfoques: esto, en mi opinión, es lo que distingue a la conferencia del resto. Entonces, por ejemplo, al final del segundo día de la conferencia, literalmente al final del telón, Dmitry zavalishin ( dzavalishin ), uno de los organizadores, provocó una acalorada discusión sobre el hecho de que el lenguaje de programación C estaba desactualizado y era necesario desarrollarlo (incluidos los sistemas operativos) al menos en lenguajes gestionados por memoria. Presentaré mi visión de esta discusión y otros temas de interés para mí planteados en la conferencia en este artículo. Para quién es interesante, pregunto bajo kat.

Exposición

No comenzaré con una revisión de los informes, sino con la exposición, que es parte de la conferencia. Varias empresas han mostrado su desarrollo en el campo del software de sistemas. Estos son principalmente sistemas operativos, pero, por ejemplo, la compañía RED SOFT, además del sistema operativo, introdujo la "Base de datos RED" de DBMS basada en el proyecto "Firebird" . Ya mencioné este DBMS durante la revisión de una de las conferencias anteriores de OSDay . La nueva información para mí fue que fue portado a la arquitectura Elbrus .

El soporte para la arquitectura de Elbrus se anunció en productos de otros expositores. La información que el sistema operativo Alt-Linux ejecuta en los procesadores Elbrus, por supuesto, no se convirtió en noticia para mí. Los empleados de Basalt-SPO, como de costumbre, presentaron un stand basado en Elbrus y demostraron el funcionamiento de su sistema operativo en esta plataforma. Pero el hecho de que en el banner de QP OS, del que también hablé varias veces en las revisiones de la conferencia , declarara apoyo para los procesadores Elbrus, me sorprendió. Después de todo, hicimos muchos esfuerzos para portar Embox a esta arquitectura, sobre la cual también escribimos en el hub Resultó que, desafortunadamente, este no es un puerto completo para la arquitectura e2k, el lanzamiento se realizó en el modo de traducción de comandos x86, que, como saben, está presente en los procesadores Elbrus.

El soporte para varias plataformas de hardware fue una característica de todos los expositores (con la excepción de RusBITech-Astra, pero ellos, como saben, tienen su propio nicho). RED SOFT mostró su sistema operativo RED (si entendí correctamente, entonces este es el sucesor de GosLinux, que figura en el registro de software nacional) en RaPi. QP OS ha declarado soporte para ARM. Pero, con mucho, Alt Linux fue la plataforma más cruzada. Los colegas mostraron trabajo no solo en Elbrus y Baikal domésticos, sino también, por ejemplo, en una arquitectura relativamente rara como RISC-V .

Seguridad de la información

El tema de la seguridad del software es muy amplio. En la conferencia varias veces se explicó que hay varios tipos diferentes de seguridad, más precisamente definiciones de qué es la seguridad. Vienen de la seguridad inglesa, la seguridad, la fiabilidad, etc. Por lo tanto, el orador usualmente hablaba sobre qué tipo de seguridad en cuestión en este momento. Aunque todos estuvieron de acuerdo en que es difícil hablar sobre seguridad de la información (seguridad), si la seguridad funcional (seguridad) no está garantizada.

La convención de dividir en seguridad: la seguridad era claramente visible en la sección sobre seguridad de la información. Por ejemplo, Alexander Popov ( a13xp0p0v ), un desarrollador de kernel de Linux que hizo una presentación "Cómo STACKLEAK mejora la seguridad del kernel de Linux" en una conferencia anterior , presentó un informe "Mapa de características de seguridad del kernel de Linux", y el mapa muestra que la clave para la seguridad de la información reside en áreas de software de calidad. Después de todo, la mayoría de los problemas de seguridad son estándar: desbordamientos del búfer, desbordamientos de la pila, no borrar la pila al regresar de una llamada del sistema, etc. Puede ver su proyecto en github . Ayer publicado en un habr

El problema de la vaguedad del concepto de seguridad de software también se demostró en un informe de Ekaterina Rudina de Kaspersky Lab "El modelo de madurez de la seguridad de Internet de las cosas para establecer, coordinar y limitar los requisitos para los sistemas operativos". Del informe se desprende que el concepto de seguridad puede variar cuando se aplica a diferentes áreas, e incluso a diferentes tipos de dispositivos y productos. Lo cual es obvio, bueno, por qué, por ejemplo, un antivirus en su pulsera de fitness. Por lo tanto, el Consorcio de Internet Industrial , que incluye Kaspersky Lab, propuso utilizar el Modelo de Madurez de Seguridad IoT (IoT SMM) para formular el concepto de seguridad para un caso particular.

Creo que, debido a la difícil separabilidad de la seguridad, no hubo muchos informes sobre la seguridad de la información pura. Un vívido ejemplo de tal discurso fue un informe del comisionado de OpenSSL Dmitry Belyavsky, "Hosting de software: un enfoque del mundo del código abierto". En el que el autor habló sobre las dificultades de apoyar los estándares nacionales de criptografía.

Seguridad funcional

La seguridad funcional (software de seguridad) de una forma u otra estuvo presente en casi todos los informes de la conferencia. Después de todo, si miras más profundamente, incluso en la discusión ya mencionada sobre la obsolescencia del lenguaje C, se entendió que este lenguaje no es seguro y con su ayuda es muy simple "dispararte en el pie".

A juzgar por los informes en la conferencia, el uso de herramientas mejora la seguridad funcional (confiabilidad) del software para los participantes. Aunque, quizás esto sea un homenaje al tema declarado de la conferencia: las herramientas. Por lo tanto, la gran mayoría de los informes propusieron precisamente un enfoque instrumental. Uno de los organizadores de la conferencia ISP RAS se especializa en el desarrollo de herramientas para el análisis de código estático y dinámico. En realidad, ISP RAS marcó la pauta con un discurso de Alexander Gerasimov con un informe "Uso de herramientas de análisis automático de programas en el ciclo de desarrollo de software seguro".

Sobre el tema del desarrollo de analizadores estáticos, hubo un informe de Vladimir Kozyrev de la compañía Advalange "Desarrollo de herramientas para recopilar y analizar la cobertura del software a bordo". El conjunto de herramientas presentado se desarrolló con el propósito de verificar el software integrado de acuerdo con el estándar DO-178C , pero el mismo conjunto de herramientas se puede usar no solo en el software integrado, porque el código analizado para la cobertura es C.

Además de los informes sobre el desarrollo de herramientas, hubo varios informes sobre la experiencia de usar herramientas similares (o las mismas). Por ejemplo, un informe de Pyotr Devyanin de RusBITech -Astra con el largo título "Experiencia en el uso de herramientas para aumentar la confianza en los mecanismos de seguridad de la edición especial de OSRA Astra Linux" habló sobre la experiencia de aplicar estas herramientas a un módulo de seguridad para su sistema operativo.

Naturalmente, no solo se presentaron herramientas de análisis de software en la conferencia, sino también otras, con la ayuda de las cuales es posible aumentar la confiabilidad del software. Fue muy interesante escuchar a Dmitry Dagaev con el informe "Tecnologías Oberon escalables como medio de asegurar software seguro para sistemas críticos". El autor del informe es el diseñador jefe de SCADA QMS para centrales nucleares. Por lo tanto, experiencia de primera mano con sistemas con "mayores requisitos en términos de seguridad funcional y protección contra amenazas cibernéticas" (cita de la anotación a su informe). Para aumentar la seguridad del software, el autor sugiere usar la tecnología Oberon . El autor del lenguaje Oberon, Nikolaus Wirth , planteó la idea de introducir restricciones, lo que reduce significativamente el riesgo de escribir software inseguro. Al mismo tiempo, con la ayuda del refinamiento del compilador, el autor del informe sugiere crear imágenes destinadas a diversas tareas y plataformas. El informe fue muy cercano a mí, ya que en Embox se nos ocurrieron ideas similares sobre limitaciones. Pero sugirieron que se introdujeran restricciones usando el lenguaje de descripción del módulo (un lenguaje declarativo de la propia composición dirigido a una tarea específica). Y para generar artefactos que le permitan crear imágenes para una tarea específica, en nuestra opinión, también es más fácil usar un lenguaje separado para describir estos artefactos.

Como resultado, los organizadores de la conferencia resumieron en una sección informes sobre varios enfoques para proteger el software, principalmente en seguridad funcional. El primer enfoque es usar herramientas para el análisis de código, el segundo es usar lenguajes de un nivel superior y, finalmente, el enfoque de Kaspersky Lab, que es más bien organizativo o metodológico. También hubo un informe sobre el depurador, pero mejor lo pongo en una sección separada, aunque, por supuesto, la depuración puede reducir la cantidad de errores y, por lo tanto, también aumenta la confiabilidad del software.

Herramientas de depuración

La conferencia presentó varias herramientas para depurar y perfilar el software del sistema.
Valery Egorov de la compañía NTP "Cryptosoft" (creador del sistema operativo QP ) habló sobre el depurador PathFinder, que se utiliza en su hipervisor QP VMM. Naturalmente, todos ellos, con todas las ventajas y desventajas resultantes.

Denis Silakov , arquitecto sénior de sistemas, Virtuozzo
Habló sobre la experiencia de encontrar errores basados ​​en la ABRT (Herramienta automática de informe de errores). Construir un registro de todo lo que puede ser útil para el análisis, enviar un informe en caso de emergencia al servidor, y análisis adicionales ya en el servidor.

Fedor Chemerev de NIISI RAS habló sobre las instalaciones de rastreo en el sistema operativo del RV de la familia Baget. Dado que el Baget RTOS se centra en los sistemas integrados, en el caso de Virtuozzo, la información también se recopila en la máquina instrumental y el análisis se realiza en el servidor. La información se recopila escribiendo en el registro de eventos, mientras que el registro se puede analizar sin situaciones de emergencia.

Enfoque modular

La primera charla sobre herramientas que promueven la modularidad del software y los beneficios de la modularidad fue la charla ya mencionada sobre la tecnología de Oberon .

Además, hubo tres informes más, cada uno de los cuales propuso su propio enfoque al problema de garantizar la modularidad. Dmitry Alekseev de Eremeks LLC presentó el informe "Inyección de dependencia en software orientado a componentes en C / C ++". En él, el autor habló sobre cambiar la configuración de varios módulos del kernel del sistema operativo FX-RTOS y también varias interfaces. Se ha implementado un proyecto macro. Lea más en el artículo sobre Habr .

Yo, Anton Bondarev , como participante en el proyecto Embox, presenté un informe "Experiencia en el desarrollo y uso de un sistema de ensamblaje basado en un lenguaje de programación especializado", en el que hablé sobre nuestra experiencia en el desarrollo del lenguaje Mybuild, que fue parcialmente escrito en el centro . En nuestro caso, la modularidad y la implementación de dependencias se proporcionan mediante archivos separados, que describen los módulos en un lenguaje declarativo.

Y el tercero es un informe de Mullachiev Kurbanmagomed de ISP RAS "Sobre el uso de un enfoque modular en sistemas operativos integrados". Esta herramienta se utilizó en otro sistema operativo JetOS. Para describir los módulos, se utiliza el lenguaje YAML. Desafortunadamente, no se dieron ejemplos, pero la idea expresada fue muy interesante y la estamos considerando en nuestro proyecto. La idea es exportar (declarar) una interfaz y los objetos se pueden conectar a través de esta interfaz. Se expresó la idea de que los autores reinventaron IDL . Pero ciertamente este no es el caso, solo ideas cercanas.

Tal cantidad de informes sobre un enfoque modular o de componentes probablemente indica la importancia del modelo de componentes para crear software confiable. Después de todo, nadie duda de que un enfoque modular puede reducir la complejidad del software y, por lo tanto, su confiabilidad; que la estructura correcta (arquitectura) del software da resultados sorprendentes; que la API correcta (esencialmente un contrato de software) hace que el software sea más compatible. Pero es más fácil decir que necesita hacer la interfaz correcta que implementarla. Por ejemplo, un informe sobre Oberon sugiere el uso de módulos sin estado. Naturalmente, esto resuelve el problema, pero personalmente nunca he visto un sistema real que no tenga un estado.

Volviendo a la discusión sobre la obsoleta C

Los problemas de usar el lenguaje C son obvios, por lo tanto, se utilizan todo tipo de formas de resolverlos, y analizadores estáticos, y varios tipos de pruebas, y mucho más. Surge una pregunta razonable: ¿por qué gastar tanto esfuerzo?
Dado que la discusión fue abierta y se proporcionó un micrófono a todos, fue claramente visible que algunos de los participantes de la conferencia apoyaron plenamente esta idea, y algunos expresaron varias dudas de que el lenguaje C sería algo del pasado, al menos en el campo de la programación de sistemas en un futuro próximo.

Primero, daré los argumentos de la parte de los participantes que apoyó la idea. Obviamente, la idea fue apoyada por Dmitry Dagaev, el autor del informe sobre Oberon. Como argumento, citó una fotografía de donde, en la foto con Nikolaus Wirth, está sosteniendo un póster con la inscripción de que solo debes enseñar programación en Oberon. Otros participantes en la discusión presentaron la tesis de que la arquitectura von Neumann estaba algo desactualizada, bueno, al menos puede usar memoria etiquetada, como en la arquitectura Elbrus. Y no se trataba de la arquitectura de Elbrus, sino de las tendencias modernas en la arquitectura ARM, y Alexander Popov, ya mencionado, dijo esto. Naturalmente, hubo inmediatamente aquellos que querían escribir un sistema operativo, algunas de cuyas funciones se implementarán en el hardware. Una serie completa de participantes, desarrollando el tema del uso de otro lenguaje, naturalmente, sugirió usar lenguajes de programación funcionales. Al desarrollar el tema del lenguaje, llegamos a la conclusión de que, en nuestro país, no hay herramientas de desarrollo certificadas, por ejemplo, un compilador para ARM, y los compiladores que pueden usarse pueden contener marcadores. Por lo tanto, es obvio que primero debe crear un compilador, y solo luego escribir software basado en él, incluidos los sistemas operativos.

Los argumentos de la segunda parte de los participantes en la discusión no estaban tan a favor del uso del lenguaje C, sino que explicaron por qué este lenguaje sigue siendo el estándar para la creación de núcleos del sistema operativo. Tales argumentos sonaron. La sintaxis del lenguaje C implica un control completo y explícito por parte del programador de todo en el programa, incluida la asignación de memoria, que le permite crear algoritmos muy eficientes en recursos. El lenguaje C es compatible con herramientas de desarrollo, por ejemplo, gcc. La sintaxis del lenguaje es muy simple y familiar para un gran número de personas.

Realmente me gustó la alegoría con naves espaciales y caminos viejos. Partiendo de ello, ahora se utilizan automóviles comunes, que probablemente no son muy buenos, contaminan el medio ambiente y tienen una gran tasa de accidentes. Pero para cambiar a algunos superdeportivos no tripulados, es probable que necesite crecer, construir una red de carreteras de calidad adecuada, reabastecerse de combustible, desarrollar algoritmos, etc. El trabajo en estas áreas está en marcha, pero es improbable que tome y prohíba automóviles viejos como este.

Estoy totalmente de acuerdo, primero debe desarrollar la industria y capacitar a especialistas, y estos son procesos muy largos, por ahora debe usar un montón de software ya desarrollado en C, ya que es mucho más confiable y más depurado que el recién creado, aunque con tecnologías avanzadas. De hecho, aunque no en esta discusión, tales advertencias sonaron en la conferencia. Por ejemplo, el autor del informe de alojamiento de software criptográfico, Dmitry Belyavsky, cuando se le preguntó qué necesita saber el desarrollador de seguridad, respondió: "nunca escriba usted mismo la criptografía". Y Dmitry Shevtsov de FSTEC, me pidió que me encargara más de apoyar el software desarrollado.

En cuanto a la capacitación de especialistas, probablemente sea la pregunta más importante: qué piensan los expertos: el software se desarrollará sobre eso, es muy posible que el lenguaje C se haya convertido en el estándar de facto para el sistema operativo, ya que tenía UNIX y Minix (y quizás por eso que fue concebido para el desarrollo de UNIX). Por lo tanto, el proyecto para enseñar a los escolares y estudiantes a programar en el idioma de Oberon Informatics 21 puede dar sus frutos, sin embargo, debe pasar mucho tiempo.

Conclusión

Como dije en la introducción, esta conferencia le permite compartir ideas, discutir y discutir. Se presentaron varios enfoques sobre muchos temas, por ejemplo, sobre software modular y software seguro. Además, los organizadores de la conferencia a sabiendas llaman a los oradores con diferentes enfoques y esto hace que la conferencia sea aún más interesante. Y, por supuesto, la conferencia es muy abierta, como dijo Dmitry Zavalishin durante la discusión sobre el lenguaje C, "Cinco minutos de gloria para todos".

PS

Acabo de leer un artículo en un centro llamado "Medios técnicos como un bazar" . Explica lo importante que es tener varias opiniones diferentes. Propongo continuar la discusión sobre el lenguaje C en Habré. Por ejemplo, es muy interesante saber si hay soluciones industriales multiplataforma en óxido o en marcha.