Недавно (10-11 июня) в Москве прошла очередная научно-практическая конференция OSDay. На этот раз конференция проходила в математическом институте им. В.А. Стеклова РАН. Формально она была посвящена инструментам разработки операционных платформ и системного программного обеспечения. Как обычно, темы, затрагиваемые на конференции, не ограничились формально заявленными, а поднятые вопросы рассматривались с разных сторон и обсуждались различные подходы к их решению. Различные взгляды и подходы — это, на мой взгляд, то, что выделяет конференцию среди остальных. Так, например, в конце второго дня конференции, буквально под занавес, Дмитрий Завалишин ( dzavalishin ), один из организаторов, спровоцировал бурную дискуссию, о том, что язык программирования Си вообще-то устарел и разрабатывать (в том числе и операционные системы) нужно, как минимум, на языках с управляемой памятью. Свое видение об этой дискуссии и других интересных мне темах, поднятых на конференции, я изложу в данной статье. Кому интересно прошу под кат.
Выставка
Начну не с обзора докладов, а с выставки, которая является частью конференции. Несколько компаний показали свои разработки в области системного ПО. В основном это операционные системы, но, например, компания РЕД СОФТ кроме ОС представила СУБД “РЕД База данных” основанную на проекте “Firebird”. Об этой СУБД я уже упоминал при обзоре одной из прошлых конференций OSDay. Новой информацией для меня стало то, что она портирована на архитектуру Эльбрус.
Поддержка архитектуры Эльбрус была заявлена в продуктах и у других участников выставки. Информация о том, что ОС Альт-Linux исполняется на процессорах Эльбрус, конечно, не стала для меня новостью. Сотрудники Базальт-СПО, как обычно, привезли стенд на базе Эльбруса и продемонстрировали работу своей ОС на этой платформе. А вот то, что на баннере QP ОС, о которой я также несколько раз уже рассказывал в обзорах конференции, заявлена поддержка поцессоров Эльбрус, меня удивило. Ведь мы приложили немало усилий чтобы портировать Embox на данную архитектуру, о чем также писали на хабре. Выяснилось, что к сожалению, это не полноценный порт под архитектуру e2k, запуск был осуществлен в режиме трансляции команд x86, который, как известно, присутствует в процессорах Эльбрус.
Поддержка различных аппаратных платформ была фишкой всех участников выставки (за исключением компании РусБИТех -Астра, но у них, как известно, своя ниша). РЕД СОФТ показал свою РЕД ОС (если я правильно понял, то это наследник ГосЛинукс, который внесен в реестр отечественного ПО) на RaPi. У QP ОС была заявлена поддержка ARM. Но безусловно, самым кросс-платформенным выступил Альт-Линукс. Коллеги показали работу не только на отечественных Эльбрусе и Байкале, но и, например, на такой относительно редкой архитектуре как RISC-V.
Информационная безопасность
Тема безопасности ПО очень широкая. На конференции несколько раз объясняли, что существуют несколько различных типов безопасности, точнее определений, что же такое безопасность. Происходят они от английских safety, security, reliability и так далее. Поэтому докладчик обычно говорил, о какой именно безопасности идет речь в данный момент. Хотя все сходились во мнении, что трудно говорить об информационной безопасности (security), если не обеспечена функциональная безопасность (safety).
Условность разделения на security — safety была хорошо заметна на секции, посвященной информационной безопасности. Например, Александр Попов ( a13xp0p0v ), разработчик ядра Linux, который на предыдущей конференции выступал с докладом “Как STACKLEAK улучшает безопасность ядра Linux”, представил доклад “Карта средств защиты ядра Linux”, и на карте видно, что ключ к информационной безопасности лежит в области качественного ПО. Ведь большинство проблем безопасности являются стандартными: переполнение буфера, переполнение стека, не очистка стека при возврате из системного вызова и т. д. Посмотреть его проект можно на github. Вчера опубликовали на хабре.
Проблема размытости понятия безопасности ПО, также была продемонстрирована в докладе Екатерины Рудиной из Лаборатории Касперского “Модель зрелости безопасности интернета вещей для установления, согласования и ограничения требований к операционным системам”. Из доклада следовало, что понятие безопасность может различаться в применении к разным сферам, и даже к разным типам устройств и продуктов. Что очевидно, ну зачем, например, на вашем фитнес браслете антивирус. Поэтому в Industrial Internet Consortium, в котором состоит и Лаборатория Касперского, предложили использовать модель зрелости безопасности интернета вещей (IoT Security Maturity Model, IoT SMM) для формулировки понятия безопасности для конкретного случая.
Думаю, по причине трудной отделяемости security и safety докладов по чистой информационной безопасности было не очень много. Ярким примером такого выступления был доклад от комиттера OpenSSL Дмитрия Белявского “Гостификация ПО: подход из мира Open Source”. В котором автор рассказал, о трудностях поддержки национальных стандартов по криптографии.
Функциональная безопасность
Функциональная безопасность (safety software) в том или ином виде присутствовала практически во всех докладах на конференции. Ведь если посмотреть глубже, то даже в уже упомянутой дискуссии по поводу устаревания языка Си подразумевалось, что данный язык небезопасен и с его помощью очень просто “выстрелить себе в ногу”.
Судя по докладам на конференции, улучшение функциональной безопасности (надежности) ПО участникам видится в применении инструментальных средств. Хотя, возможно, это дань заявленной теме конференции — инструменты. Поэтому подавляющее большинство докладов предлагало именно инструментальный подход. Один из организаторов конференции ИСП РАН специализируется на разработке инструментов для статического и динамического анализа кода. Собственно ИСП РАН и задал тон выступлением Александра Герасимова c докладом “Применение инструментов автоматического анализа программ в цикле разработки безопасного ПО”.
По теме разработки статических анализаторов был доклад от Владимира Козырева из компании Advalange “Разработка инструментария сбора и анализа покрытия бортового программного обеспечения”. Представленный инструментарий был разработан для целей верификации бортового ПО по стандарту DO-178C, но этот же инструментарий может быть использован не только в бортовом ПО, ведь анализируемый код на покрытие это обычный Си.
Кроме докладов про разработку инструментов, было несколько докладов про опыт использования подобных (или этих же) инструментов. Например, доклад Петра Девянина из РусБИТех-Астра с длинным названием “Опыт применения инструментальных средств для повышения доверия к механизмам защиты ОССН Astra Linux Special Edition” рассказывал об опыте применения этих инструментов к модулю системы безопасности для их ОС.
Естественно, на конференции были представлены не только инструменты анализа ПО но и другие, с помощью которых можно повысить надежность ПО. Очень интересно было послушать Дмитрия Дагаева с докладом “Масштабируемые Оберон-технологии как средства обеспечения защищенного ПО критически важных систем”. Автор доклада является главным конструктором SCADA СУОК для АЭС. Поэтому не понаслышке сталкивался с системами с “повышенными требованиями в части функциональной безопасности и защиты от кибер-угроз” (цитата из аннотации к его докладу). Для увеличение безопасности ПО автор предлагает использовать Оберон технологии. Автор языка Оберон Николаус Вирт, вложил идею внесения ограничений, что существенно уменьшает риск написания небезопасного ПО. При этом с помощью доработки компилятора автор доклада, предлагает создавать образы, нацеленные на различные задачи и платформы. Доклад был мне очень близок, поскольку мы в Embox пришли к похожим идеям по ограничениям. Но предложили ограничения вносить с помощью языка описания модулей ( декларативного языка собственного сочинения нацеленного на конкретную задачу). И для генерации артефактов позволяющих создавать образы под конкретную задачу, на наш взгляд, также проще использовать отдельный язык для описания этих артефактов.
В итоге организаторы конференции свели в одной секции доклады по различным подходам к безопасному ПО, речь в первую очередь о функциональной безопасности. Первый подход — использовать инструментарий для анализа кода, второй — использовать языки более высокого уровня и, наконец, подход лаборатории Касперского, который является скорее организационным или методическим. Был еще доклад про отладчик, но я лучше вынесу его в отдельную секцию, хотя, безусловно, отладка позволяет снизить количество ошибок и, следовательно, тоже увеличивает надежность ПО.
Средства отладки
На конференции были представлены несколько средств отладки и профилирования системного ПО.
Валерий Егоров из компании НТП «Криптософт» (создатель QP ОС) рассказал об отладчике PathFinder, который используется в их гипервизоре QP VMM. Естественно, все свое, со всеми вытекающими достоинствами и недостатками.
Денис Силаков, старший системный архитектор, Virtuozzo
Рассказал об опыте поиска ошибок, основанном на ABRT (Automatic Bug Reporting Tool). Сборка лога всего, что может пригодиться для анализа, отправка отчета при возникновении внештатной ситуации на сервер, и дальнейший анализ уже на сервере.
Федор Чемерев из НИИСИ РАН рассказал про средства трассировки в ОС РВ семейства “Багет”. Поскольку ОСРВ “Багет” ориентирована на встраиваемые системы, то и в случае Virtuozzo на инструментальной машине происходит сбор информации, а анализ происходит на сервере. Сбор информации происходит путем записи в журнал событий, при этом журнал может анализировать и без внештатных ситуаций.
Модульный подход
Первым докладом про инструментарий, способствующий модульности ПО и преимуществах модульности, был уже упомянутый доклад про Оберон технологии.
Кроме этого были еще целых три доклада, каждый из которых предлагал собственный подход к проблеме обеспечения модульности. Дмитрий Алексеев из ООО «Эремекс» представил доклад “Внедрение зависимостей в компонентно-ориентированном ПО на C/C++”. В нем автор рассказал о переключении конфигурации различных модулей ядра ОС FX-RTOS и также различных интерфейсов. Реализован проект на основе макросов. Подробнее в статье на хабре.
Я, Антон Бондарев, как участник проекта Embox, представил доклад “Опыт разработки и применения системы сборки на основе специализированного языка программирования”, в котором рассказал о нашем опыте разработки языка Mybuild о чем частично писали на хабре. В нашем случае модульность и внедрение зависимостей обеспечивается с помощью отдельных файлов, в которых на декларативном языке описываются модули.
И третий это доклад от Маллачиева Курбанмагомеда из ИСП РАН “Об использовании модульного подхода во встраиваемых операционных системах”. Данный инструмент был использован в еще одной ОС JetOS. Для описание модулей используется язык YAML. К сожалению, не было приведено примеров, но озвученная идея была очень интересна и мы ее обдумываем в нашем проекте. Идея заключается в том, чтобы экспортировать (декларировать) интерфейс и объекты могут подключаться именно через этот интерфейс. Была озвучена мысль, что авторы переизобрели IDL. Но это конечно не так, просто близкие идеи.
Такое количество докладов по модульному или компонентному подходу, наверное, указывает на важность компонентной модели, для создания надежного ПО. Ведь ни у кого не возникает сомнений в том, что модульный подход может уменьшить сложность ПО, а следовательно и его надежность; что правильная структура (архитектура) ПО дает поразительные результаты; что правильный API (по сути дела контракт для ПО) делает ПО более поддерживаемым. Но легче сказать о том, что нужно сделать правильный интерфейс, чем реализовать его. Например, в докладе про Оберон предполагается использовать модули без состояния. Естественно, это решает проблему, но лично я никогда не видел реальной системы, которая не имела бы состояния.
Возвращаясь к дискуссии об устаревшем Си
Проблемы применения языка Си очевидны, поэтому и применяются всевозможные способы их решения, и статические анализаторы, и различные виды тестирования, и еще много чего. Возникает резонный вопрос: а зачем тратить столько усилий?
Поскольку дискуссия была открытая и каждому желающему предоставлялся микрофон было хорошо видно, что часть участников конференции полностью поддержала данную идею, а часть высказала разного рода сомнения в том, что язык Си уйдет в прошлое, по крайней мере в области системного программирования в ближайшем будущем.
Сначала приведу аргументы той части участников, которая поддержала идею. Очевидно, что идею поддержал Дмитрий Дагаев, автор доклада про Оберон. В качестве аргумента он привел фотографию где, он на снимке с Николаусом Виртом держит плакат с надписью о том, что обучать программированию нужно только на Обероне. Другие участники дискуссии выдвинули тезис, что и архитектура фон Неймана, несколько устарела, ну как минимум можно использовать тегированную память, как в архитектуре Эльбрус. Причем речь шла не об архитектуре Эльбрус, а о современных тенденциях архитектуры ARM, и сообщил об этом уже упомянутый Александр Попов. Естественно, тут же нашлись желающие написать ОС, часть функций которой будет реализована аппаратно. Еще целый ряд участников, развивая тему использования другого языка, естественно, предложили использовать функциональные языки программирования. Развивая тему языка, пришли к выводу, что, оказывается, у нас в стране нет сертифицированных средств разработки, например, компилятора под ARM, да и компиляторы, которые разрешены к использованию, могут содержать закладки. Поэтому очевидно, что сначала нужно создать компилятор, а уж потом на его основе писать ПО, в том числе и операционные системы.
Аргументы второй части участников дискуссии, были не то чтобы в пользу использования языка Си, скорее они объясняли, почему этот язык до сих пор является стандартом для создания ядер ОС. Звучали такие аргументы. Синтаксис языка Си подразумевает полный и явный контроль программистом всего в программе, в том числе и выделения памяти, что позволяет создавать очень эффективные с точки зрения ресурсов алгоритмы. Язык Си, действительно, поддерживается средствами разработки, взять например gcc. Синтаксис языка очень простой и знаком очень большому количеству людей.
Мне очень понравилась аллегория с космолетами и старыми дорогами. Исходя из нее, сейчас используются обычные машины, которые, наверное, не очень хороши, загрязняют окружающую среду и имеют большую аварийность. Но для того, чтобы перейти на какие-нибудь беспилотные суперкары, наверное, нужно до них дорасти, построить сеть дорог соответствующего качества, заправки, разработать алгоритмы и так далее. Работы в этих направлениях ведутся, но чтобы вот так взять и запретить старые машины — такое вряд ли получится.
Абсолютно согласен, сначала нужно развить индустрию и обучить специалистов, а это очень долгие процессы, пока же приходиться использовать кучу уже разработанного ПО на языке Си, поскольку оно гораздо надежнее и более отлаженное, чем вновь созданное, пусть и на передовых технологиях. Ведь хоть и не на данной дискуссии, но на конференции звучали подобные предостережения. Например, автор доклада о гостификации криптографического ПО Дмитрий Белявский на вопрос, что нужно знать разработчику занимающемуся безопасностью, ответил, “никогда не пишите криптографию самостоятельно”. А Дмитрий Шевцов из ФСТЭК, попросил больше заботиться о поддержке разработанного ПО.
Про обучение специалистов, наверное, самый важный вопрос: на чем “думают“ специалисты — на том и будет разработано ПО, вполне возможно, что язык Си стал стандартом де факто для ОС, поскольку в нем были UNIX и Minix (а может, именно потому, что был задуман для разработки UNIX). Поэтому проект обучения школьников и студентов программированию на языке Оберон Информатика 21 может дать свои плоды, правда, должно пройти немало времени.
Заключение
Как я уже сказал во введении, данная конференция позволяет делиться идеями, обсуждать и дискутировать. По многим вопросам были представлены несколько подходов, например, про модульное ПО и безопасное ПО. Причем организаторы конференции сознательно зовут докладчиков с разными подходами и это делает конференцию еще более интересной. Ну и конечно, конференция очень открытая, как сказал Дмитрий Завалишин в ходе дискуссии об языке Си, “Пять минут славы каждому“.
P.S.
Только что прочитал статью на хабре под названием “ Технические СМИ как базар”. В ней объясняется, как важно иметь несколько различных мнений. Предлагаю продолжить дискуссию о языке Си на Хабре. Например, очень интересно узнать, есть ли кросс-платформенные промышленные решения на rust или go?
Автор: abondarev
