Dia 19 ou por que a linguagem C ainda está viva

Recentemente (10 a 11 de junho), a próxima conferência científico-prática da OSDay foi realizada em Moscou. Desta vez, a conferência foi realizada no Instituto de Matemática. V.A. Steklov RAS. Formalmente, foi dedicado a ferramentas de desenvolvimento para plataformas operacionais e software de sistema. Como de costume, os tópicos abordados na conferência não se limitaram ao formalmente declarado, e as questões levantadas foram consideradas sob diferentes ângulos e várias abordagens de sua solução foram discutidas. Diferentes visões e abordagens - isso, na minha opinião, é o que distingue a conferência do resto. Então, por exemplo, no final do segundo dia da conferência, literalmente no final da cortina, Dmitry zavalishin ( dzavalishin ), um dos organizadores, provocou uma discussão acalorada sobre o fato de que a linguagem de programação C estava realmente desatualizada e era necessário desenvolver (incluindo sistemas operacionais) pelo menos em idiomas gerenciados por memória. Vou apresentar minha visão desta discussão e outros tópicos de interesse levantados na conferência neste artigo. Para quem é interessante, pergunto sob kat.

Exposição

Começarei não com uma revisão dos relatórios, mas com a exposição, que faz parte da conferência. Várias empresas mostraram seu desenvolvimento no campo de software de sistema. Estes são principalmente sistemas operacionais, mas, por exemplo, a empresa RED SOFT, além do sistema operacional, introduziu o "Banco de Dados RED" do DBMS com base no projeto "Firebird" . Eu já mencionei esse DBMS durante a revisão de uma das conferências anteriores do OSDay . Uma nova informação para mim foi que ela era portada para a arquitetura Elbrus .

O suporte à arquitetura Elbrus foi anunciado em produtos de outros expositores. As informações que o sistema operacional Alt-Linux executa nos processadores Elbrus, é claro, não se tornaram novidade para mim. Os funcionários da Basalt-SPO, como sempre, fizeram um stand com base na Elbrus e demonstraram a operação de seu sistema operacional nessa plataforma. Mas o fato de o banner QP OS, sobre o qual eu também falei várias vezes nas análises da conferência , reivindicar suporte aos processadores Elbrus, me surpreendeu. Afinal, fizemos um grande esforço para portar a Embox para essa arquitetura, sobre a qual também escrevemos no hub Infelizmente, essa não é uma porta completa para a arquitetura e2k, o lançamento foi realizado no modo de conversão de comando x86, que, como você sabe, está presente nos processadores Elbrus.

O suporte a várias plataformas de hardware era uma característica de todos os expositores (com exceção da RusBITech-Astra, mas eles, como você sabe, têm seu próprio nicho). O RED SOFT mostrou seu sistema operacional RED (se bem entendi, esse é o sucessor do GosLinux, listado no registro de software doméstico) no RaPi. O QP OS declarou suporte ao ARM. Mas, de longe, o Alt Linux era o mais multiplataforma. Os colegas mostraram trabalho não apenas no Elbrus e Baikal doméstico, mas também, por exemplo, em uma arquitetura relativamente rara como o RISC-V .

Segurança da informação

O tópico de segurança de software é muito amplo. Na conferência, várias vezes foi explicado que existem vários tipos diferentes de segurança, mais precisamente definições do que é segurança. Eles vêm de inglês segurança, segurança, confiabilidade e assim por diante. Portanto, o palestrante geralmente falava sobre que tipo de segurança em questão no momento. Embora todos concordem que é difícil falar sobre segurança da informação (segurança), se a segurança funcional (segurança) não for garantida.

A convenção de dividir em segurança - segurança era claramente visível na seção sobre segurança da informação. Por exemplo, Alexander Popov ( a13xp0p0v ), um desenvolvedor de kernel do Linux que fez uma apresentação “Como STACKLEAK melhora a segurança do kernel do Linux” em uma conferência anterior , apresentou o “mapa de recursos de segurança do kernel do Linux” e o mapa mostra que a chave para a segurança da informação está em áreas de software de qualidade. Afinal, a maioria dos problemas de segurança é padrão: estouros de buffer, estouros de pilha, não limpar a pilha ao retornar de uma chamada do sistema etc. Você pode ver o projeto dele no github . Publicado ontem em um habr

O problema da imprecisão do conceito de segurança de software também foi demonstrado em um relatório de Ekaterina Rudina, da Kaspersky Lab: “O modelo de maturidade da segurança da Internet das coisas para estabelecer, coordenar e limitar os requisitos de sistemas operacionais”. Seguiu-se do relatório que o conceito de segurança pode variar quando aplicado a diferentes áreas e até a diferentes tipos de dispositivos e produtos. O que é óbvio, bem, por que, por exemplo, um antivírus na sua pulseira de fitness. Portanto, o Industrial Internet Consortium , que inclui a Kaspersky Lab, propôs o uso do IoT Security Maturity Model (IoT SMM) para formular o conceito de segurança para um caso específico.

Penso que, devido à difícil separabilidade entre segurança e proteção, não havia muitos relatórios sobre pura segurança da informação. Um exemplo vívido desse discurso foi um relatório do comissário do OpenSSL Dmitry Belyavsky, “Hospedagem de software: uma abordagem do mundo do código aberto”. Em que o autor falou sobre as dificuldades de apoiar os padrões nacionais de criptografia.

Segurança funcional

A segurança funcional (software de segurança), de uma forma ou de outra, estava presente em quase todos os relatórios da conferência. Afinal, se você olhar mais fundo, mesmo na discussão já mencionada sobre a obsolescência da linguagem C, entendeu-se que essa linguagem é insegura e com sua ajuda é muito fácil "dar um tiro no pé".

A julgar pelos relatórios da conferência, a melhoria da segurança funcional (confiabilidade) do software para os participantes é vista no uso de ferramentas. Embora, talvez este seja um tributo ao tema declarado da conferência - ferramentas. Portanto, a grande maioria dos relatórios propôs precisamente uma abordagem instrumental. Um dos organizadores da conferência ISP RAS é especializado no desenvolvimento de ferramentas para análise de código estático e dinâmico. Na verdade, o ISP RAS deu o tom com um discurso de Alexander Gerasimov com um relatório "Usando ferramentas automáticas de análise de programas no ciclo de desenvolvimento de software seguro".

Sobre o tema do desenvolvimento de analisadores estáticos, houve um relatório de Vladimir Kozyrev, da empresa Advalange, “Desenvolvimento de ferramentas para coletar e analisar a cobertura do software de bordo”. O kit de ferramentas apresentado foi desenvolvido com o objetivo de verificar o software de bordo de acordo com o padrão DO-178C , mas o mesmo kit de ferramentas pode ser usado não apenas no software de bordo, porque o código analisado para cobertura é comum C.

Além dos relatórios sobre o desenvolvimento de ferramentas, houve vários relatórios sobre a experiência do uso de ferramentas semelhantes (ou iguais). Por exemplo, um relatório de Pyotr Devyanin da RusBITech -Astra com o título longo “Experiência com o uso de ferramentas para aumentar a confiança nos mecanismos de segurança da OSRA Astra Linux Special Edition” falou sobre a experiência de aplicar essas ferramentas a um módulo de segurança para o seu SO.

Naturalmente, não foram apresentadas apenas ferramentas de análise de software na conferência, mas também outras, com a ajuda da qual é possível aumentar a confiabilidade do software. Foi muito interessante ouvir Dmitry Dagaev com o relatório “Scalable Oberon Technologies como meio de proteger software seguro para sistemas críticos”. O autor do relatório é o designer-chefe do SCADA QMS para usinas nucleares. Portanto, experiência em primeira mão com sistemas com “aumento de requisitos em termos de segurança funcional e proteção contra ameaças cibernéticas” (citação da anotação em seu relatório). Para aumentar a segurança do software, o autor sugere o uso da tecnologia Oberon . O autor do idioma Oberon, Nikolaus Wirth , colocou a idéia de introduzir restrições, o que reduz significativamente o risco de escrever software inseguro. Ao mesmo tempo, com a ajuda do refinamento do compilador, o autor do relatório sugere a criação de imagens destinadas a várias tarefas e plataformas. O relatório estava muito próximo de mim, pois nós da Embox tivemos idéias semelhantes sobre limitações. Mas eles sugeriram que as restrições fossem introduzidas usando a linguagem de descrição do módulo (uma linguagem declarativa da própria composição destinada a uma tarefa específica). E para gerar artefatos que permitem criar imagens para uma tarefa específica, em nossa opinião, também é mais fácil usar um idioma separado para descrever esses artefatos.

Como resultado, os organizadores da conferência resumiram em uma seção relatórios sobre várias abordagens para proteger software, principalmente sobre segurança funcional. A primeira abordagem é usar ferramentas para análise de código, a segunda é usar linguagens de nível superior e, finalmente, a abordagem do Kaspersky Lab, que é bastante organizacional ou metodológica. Havia também um relatório sobre o depurador, mas é melhor colocá-lo em uma seção separada, embora, é claro, a depuração possa reduzir o número de erros e, portanto, também aumentar a confiabilidade do software.

Ferramentas de depuração

A conferência apresentou várias ferramentas para depuração e criação de perfil de software do sistema.
Valery Egorov, da empresa NTP "Cryptosoft" (criador do QP OS ), falou sobre o depurador do PathFinder, usado em seu hypervisor QP VMM. Naturalmente, todos eles próprios, com todas as vantagens e desvantagens resultantes.

Denis Silakov , arquiteto de sistemas sênior, Virtuozzo
Ele falou sobre a experiência de encontrar erros com base no ABRT (Automatic Bug Reporting Tool). Construir um log de tudo o que pode ser útil para análise, enviando um relatório em caso de emergência ao servidor e análises adicionais já no servidor.

Fedor Chemerev, da NIISI RAS, falou sobre instalações de rastreamento no sistema operacional do trailer da família Baget. Como o Baget RTOS é focado em sistemas embarcados, no caso do Virtuozzo, as informações também são coletadas na máquina instrumental e a análise é realizada no servidor. As informações são coletadas gravando no log de eventos, enquanto o log pode ser analisado sem situações de emergência.

Abordagem modular

A primeira palestra sobre ferramentas que promovem a modularidade de software e os benefícios da modularidade foi a já mencionada palestra sobre a tecnologia Oberon .

Além disso, havia mais três relatórios, cada um dos quais propunha sua própria abordagem para o problema de garantir a modularidade. Dmitry Alekseev, da Eremeks LLC, apresentou o relatório "Injeção de dependência em software orientado a componentes em C / C ++". Nele, o autor falou sobre mudar a configuração de vários módulos do kernel do sistema operacional FX-RTOS e também várias interfaces. Um projeto baseado em macro foi implementado. Leia mais no artigo sobre Habr .

Anton Bondarev , como participante do projeto Embox, apresentei um relatório “Experiência no desenvolvimento e uso de um sistema de montagem baseado em uma linguagem de programação especializada”, no qual falei sobre nossa experiência no desenvolvimento da linguagem Mybuild, que foi parcialmente escrita no hub . No nosso caso, a modularidade e a implementação de dependências são fornecidas usando arquivos separados, que descrevem os módulos em uma linguagem declarativa.

E o terceiro é um relatório de Mullachiev Kurbanmagomed do ISP RAS "Sobre o uso de uma abordagem modular em sistemas operacionais embarcados". Essa ferramenta foi usada em outro sistema operacional JetOS. Para a descrição dos módulos, a linguagem YAML é usada. Infelizmente, nenhum exemplo foi dado, mas a ideia expressa foi muito interessante e estamos considerando isso em nosso projeto. A idéia é exportar (declarar) uma interface e os objetos podem ser conectados por essa interface. Expressou-se a idéia de que os autores reinventaram o IDL . Mas esse certamente não é o caso, apenas idéias próximas.

Esse número de relatórios sobre uma abordagem modular ou de componente provavelmente indica a importância do modelo de componente para a criação de software confiável. Afinal, ninguém duvida que uma abordagem modular possa reduzir a complexidade do software e, portanto, sua confiabilidade; que a estrutura correta (arquitetura) do software produz resultados surpreendentes; que a API correta (essencialmente um contrato de software) torne o software mais suportado. Mas é mais fácil dizer que você precisa criar a interface certa do que implementá-la. Por exemplo, um relatório sobre Oberon sugere o uso de módulos sem estado. Naturalmente, isso resolve o problema, mas pessoalmente nunca vi um sistema real que não tenha um estado.

Voltando à discussão sobre C obsoleto

Os problemas do uso da linguagem C são óbvios, portanto, são utilizados todos os tipos de maneiras de resolvê-los, além de analisadores estáticos, vários tipos de teste e muito mais. Surge uma pergunta razoável: por que gastar tanto esforço?
Como a discussão foi aberta e um microfone foi fornecido a todos, ficou claro que alguns dos participantes da conferência apoiaram totalmente essa ideia, e alguns expressaram várias dúvidas de que a linguagem C seria uma coisa do passado, pelo menos no campo da programação de sistemas em um futuro próximo.

Primeiro, apresentarei os argumentos da parte dos participantes que apoiaram a ideia. Obviamente, a ideia foi apoiada por Dmitry Dagaev, autor do relatório sobre Oberon. Como argumento, ele citou uma fotografia de onde, na foto com Nikolaus Wirth, ele está segurando um cartaz com a inscrição de que você precisa ensinar programação apenas em Oberon. Outros participantes da discussão apresentaram a tese de que a arquitetura de von Neumann estava um pouco desatualizada. Bem, pelo menos você pode usar a memória marcada, como na arquitetura Elbrus. E não era sobre a arquitetura Elbrus, mas sobre as tendências modernas na arquitetura ARM, e Alexander Popov, já mencionado, disse isso. Naturalmente, havia imediatamente aqueles que queriam escrever um sistema operacional, algumas das funções que serão implementadas no hardware. Uma série inteira de participantes, desenvolvendo o tópico de usar outra linguagem, naturalmente, sugeriu o uso de linguagens de programação funcional. Desenvolvendo o tópico da linguagem, chegamos à conclusão de que, em nosso país, não existem ferramentas de desenvolvimento certificadas, por exemplo, um compilador para ARM, e os compiladores que podem usar podem conter marcadores. Portanto, é óbvio que você deve primeiro criar um compilador e só depois escrever um software com base nele, incluindo sistemas operacionais.

Os argumentos da segunda parte dos participantes da discussão não eram tão favoráveis ​​ao uso da linguagem C, mas explicaram por que essa linguagem ainda é o padrão para a criação de kernels de SO. Tais argumentos soaram. A sintaxe da linguagem C implica em um controle completo e explícito pelo programador de tudo o que está no programa, incluindo alocação de memória, o que permite criar algoritmos muito eficientes em termos de recursos. A linguagem C é realmente suportada por ferramentas de desenvolvimento, por exemplo, gcc. A sintaxe do idioma é muito simples e familiar para um número muito grande de pessoas.

Gostei muito da alegoria com naves espaciais e estradas antigas. A partir disso, agora são usados ​​carros comuns, que provavelmente não são muito bons, poluem o meio ambiente e têm uma grande taxa de acidentes. Mas, para mudar para alguns supercarros não tripulados, você provavelmente precisará crescer até eles, construir uma rede de estradas de qualidade adequada, reabastecer, desenvolver algoritmos e assim por diante. O trabalho nessas áreas está em andamento, mas é improvável que seja possível proibir carros antigos como esse.

Concordo absolutamente que você primeiro precisa desenvolver a indústria e treinar especialistas, e esses são processos muito longos, pois agora você precisa usar um monte de software já desenvolvido em C, pois é muito mais confiável e mais depurado que o recém-criado, embora com tecnologias avançadas. De fato, embora não nesta discussão, esses avisos soaram na conferência. Por exemplo, o autor do relatório sobre hospedagem de software criptográfico, Dmitry Belyavsky, quando perguntado o que o desenvolvedor de segurança precisa saber, respondeu: "nunca escreva criptografia você mesmo". E Dmitry Shevtsov, do FSTEC, me pediu para cuidar mais do suporte ao software desenvolvido.

Sobre o treinamento de especialistas, provavelmente é a pergunta mais importante: o que os especialistas pensam - o software será desenvolvido sobre isso, é bem possível que a linguagem C tenha se tornado o padrão de fato para o sistema operacional, já que possuía UNIX e Minix (e talvez seja por isso que foi concebido para o desenvolvimento do UNIX). Portanto, o projeto para ensinar crianças em idade escolar e alunos a programar no idioma Oberon Informatics 21 pode dar frutos, no entanto, muito tempo deve passar.

Conclusão

Como eu disse na introdução, esta conferência permite compartilhar idéias, discutir e discutir. Várias abordagens foram apresentadas em muitas questões, por exemplo, sobre software modular e software seguro. Além disso, os organizadores da conferência conscientemente chamam oradores com abordagens diferentes e isso torna a conferência ainda mais interessante. E, claro, a conferência é muito aberta, como Dmitry Zavalishin disse durante a discussão sobre a linguagem C: "Cinco minutos de glória para todos".

PS

Acabei de ler um artigo em um hub chamado "Technical Media as a Bazaar" . Explica como é importante ter várias opiniões diferentes. Proponho continuar a discussão sobre a linguagem C em Habré. Por exemplo, é muito interessante saber se existem soluções industriais de plataforma cruzada contra ferrugem ou não?