Заголовок ptsecurity.com Формальная верификация ядер операционных систем Денис Ефремов [email protected] 

Заголовок 2 • Научный сотрудник ИСП РАН ([email protected]) • Занимался проектами формальной верификации/аудита кода ядра Linux с 2014 года • Поддерживаю floppy драйвер в ядре Linux • Готовлю ядро CruelKernel для телефонов Samsung S10/Note10 • Разработчик в команде KSPLICE подготовки исправлений безопасности для ядра Linux без перезагрузки О докладчике, опыте работы с Linux 

Заголовок 3 https://app.sli.do/event/wv81wshd или https://www.sli.do/ Код: phdays10_development Задавайте вопросы онлайн 

Заголовок 4 • Спецификация - набор требований и параметров, которым удовлетворяет некоторый объект (представлена в виде мат. модели, тестовых наборов, формальной спецификации); • Верификация - проверка соответствия программного обеспечения предъявляемым к нему требованиям; • Дедуктивная верификация – представление корректности программы как набора математических утверждений, называемых условиями верификации, выполнение которых проверяется автоматическими или интерактивными доказателями теорем. Верификация 

Заголовок 5 • Компилятор и линковщик работают корректным образом • В программном обеспечении, использующемся при верификации, нет ошибок • Компьютер функционирует таким образом, как мы думаем об этом (rowhammer, spectre/meltdown, DMA) • Нижележащий слой ПО (например, ОС, прошивка сетевой карты, микрокод процессора) функционирует в рамках нашего представления о том, что он должен делать и чего делать не должен • Пользователь компьютера, если он есть, специально не «пакостит» • Выполнены формальные предположения о входных данных программы, начальном состоянии, поведении окружения • … На что опираться vs Что вы будете с этого иметь (1) 

Заголовок 6 Гарантии того, что программное обеспечение функционирует в точном соответствии с требованиями, к нему предъявляемыми, на всех входных данных, начальных состояниях, при любом поведении окружения * ** * В предположении что все предположения выполнены ** И не осталось предположений, которых мы не занесли в списочек На что опираться vs Что вы будете с этого иметь (2) 

Заголовок 7 • CertiKOS – Certified Kit Operating System • CompCert – компилятор языка Clight (Coq > Ocaml) • seL4 – микроядро L4 (Cparse > Isabelle/HOL) • HACL* – криптографическая библиотека (F*) • CakeML – верифицированная реализация ML • ANSSI-FR/x509-parser – парсер сертификатов x509 (C) • … Известные проекты 

Заголовок 8 • Orange Book: division A (verified protection) (A1, Beyond A1) • Common Criteria (EAL7) • DO-178C/DO-333 "Formal Methods Supplement to DO-178C and DO-278A” • IEC 61508 (SIL4) • ФСТЭК России ГОСТ Р ИСО/МЭК 15408 «Требованиях безопасности информации к операционным системам» профили защиты операционных систем общего назначения (типа «А») Требования регулятора 

Заголовок 9 • Verification Engineering of Safety and Security Critical Industrial Applications (Vessedia) • 3 года, 7 стран Европы, TECHNIKON, CEA, Inria, Dassault, Fraunhofer FOKUS, … • Развитие методов и инструментов для анализа кода в областях применений с меньшей критичностью, чем для особо важных приложений • Определение Security Certification Levels (SCL) для применений, где использование Common Criteria не рационально • Развитие европейского стека инструментов формальной верификации и анализа кода, такого как Frama-C • Объект исследований – IoT ОС Contiki-NG Проект Vessedia. Верификация Contiki-NG 

Заголовок 10 /*@ requires b != 0; ensures a – a % b == b * \result; */ int div(int a, int b) { return a / b; } Фреймворк Frama-C. Язык спецификаций ACSL (1) 

Заголовок 11 /*@ requires b != 0; ensures a – a % b == b * \result; */ int div(int a, int b) { return a / b; } Фреймворк Frama-C. Язык спецификаций ACSL (2) Условия верификации constant min : int = -2147483648 constant max : int = 2147483647 predicate in_bounds (n:int) = min <= n /\ n <= max type t17 function to_int t17 : int function of_int int : t17 constant a_1 : t17 constant b_1 : t17 axiom H : not b_1 = of_int 0 goal WP_parameter_div2 : not to_int b_1 = 0 /\ in_bounds (div (to_int a_1) (to_int b_1)) 

Заголовок 12 /*@ requires b != 0; ensures a – a % b == b * \result; */ int div(int a, int b) { return a / b; } Фреймворк Frama-C. Язык спецификаций ACSL (3) Условия верификации Исправление constant min : int = -2147483648 constant max : int = 2147483647 predicate in_bounds (n:int) = min <= n /\ n <= max type t17 function to_int t17 : int function of_int int : t17 constant a_1 : t17 constant b_1 : t17 axiom H : not b_1 = of_int 0 goal WP_parameter_div2 : not to_int b_1 = 0 /\ in_bounds (div (to_int a_1) (to_int b_1)) - int div(int a, int b) { - return a / b; + long div(int a, int b) { + return (long) a / b; } 

Заголовок 13 /*@ requires b != 0; ensures a – a % b == b * \result; */ int div(int a, int b) { return a / b; } Фреймворк Frama-C. Язык спецификаций ACSL (4) Условия верификации Исправление Уточнение предусловий constant min : int = -2147483648 constant max : int = 2147483647 predicate in_bounds (n:int) = min <= n /\ n <= max type t17 function to_int t17 : int function of_int int : t17 constant a_1 : t17 constant b_1 : t17 axiom H : not b_1 = of_int 0 goal WP_parameter_div2 : not to_int b_1 = 0 /\ in_bounds (div (to_int a_1) (to_int b_1)) /*@ requires b != 0; requires a != INT_MIN; ensures a – a % b == b * \result; */ int div(int a, int b) - int div(int a, int b) { - return a / b; + long div(int a, int b) { + return (long) a / b; } 

Заголовок 14 • Верифицированные функции и модули: • “Минимальные” контракты (отсутствие runtime ошибок): • AES-CCM (aes-128.c, ccm-star.c) • Кольцевой буфер (ringbufindex.c, ringbuf.c) • … • Аллокатор (logic_defs, memb.h, memb.c) • Функции работы со связными списками (logic_defs, lemmas, list.h, list.c, list_split.c, list_force_insert.c) • Найденные ошибки: • Повреждение списка при вставке элементов в list_insert • Double free в аллокаторе • Примерно 3 строки спецификаций на одну строку С (2260/767) • Минимальные контракты (21 функция 300/240) • Аллокатор (154/100, 126 условий верификации) • Списки (1446/176, 798 условий верификации, 108 – safety, 26 с Coq) Contiki-NG. Результаты верификации с Frama-C 

Заголовок 15 Contiki-NG. Формальная верификация в CI . . . MEMB LIST AES-CCM Contiki-NG Коммит diff ---a/list +++b/list list_init { ... Извлечение Pull Request Функция . . . list_add list_chop list_pop list_init Patch Передоказательство WP Pin type -void*… +list_t* Трансформации Coccinelle Bitwise -E<<2 +E*4 ... • Сохранение протоколов формальной верификации • Передоказательство измененных функций • Применение промежуточных трансформаций coccinelle для адаптации кода под формальную верификацию • Схема в Travis-CI 

Заголовок 16 • Государственная сертификация • Высокоуровневая модель системы контроля доступа на Event-B • Система контроля доступа в виде LSM модуля (аналог SELinux, AppArmor, Tomoyo …) • Реализует модуль ядра Linux с закрытым исходным кодом • Размер < 5.000 SLOC • Разработка спецификаций модели Event-B • Доказательство непротиворечивости • Доказательство выполнения инвариантов безопасности на модели • Разработка спецификаций ACSL на реализацию • Доказательство соответствия кода спецификациям • Соответствие реализации в виде LSM модуля модели Event-B формально не проверяется • Поддержка, развитие инструментов верификации (Rodin для высокоуровневых моделей Event-B, Frama-C для работы с Си кодом) • Инструментарий: https://forge.ispras.ru/projects/astraver Проект AstraVer. Верификация модуля контроля доступа «AL SE» 

Заголовок 17 Формальная модель системы защиты. Спецификация Event-B https://github.com/17451k/base-model/blob/master/base-model.txt 

Приложение/Процесс Проверка Аргументов (базовая валидация) Дискреционное Управление Доступом (DAC) Вызов LSM Структуры Данных/Ресурсы Linux Security Module (SELinux, AppArmor, и др.) Разрешить доступ в соответствии с моделью безопасности? Приложения Ядро Linux Результаты системного вызова Системный вызов Аргументы корректны DAC разрешен LSM разрешен Доступ запрещен Да/Нет 

Заголовок 19 • Размер модуля < 5 KSLOC • +400 KSLOC из подключаемых заголовочных файлов (менее 100 KSLOC из них важны при компиляции) • Занимает ~20 минут только для того чтобы запустить инструменты Frama-C и сгенерировать условия верификации • Чем с большим количеством кода приходится работать одновременно, тем хуже происходит анализ/доказательство • Контракты для вызываемых из модуля функций ядра не доказываются • Соблюдение предусловий для функций модуля защиты не доказывается в точках их вызова ядром Работа с кодом ядра Linux 

Заголовок 20 • Поддержка container_of • Поддержка указателей на функции • Полная переработка моделирования побитовых операций • Поддержка переинтерпретации указателей на целочисленные типы • Поддержка массивов нулевого размера, flexible arrays • Поддержка string literals • Добавлены шаблонные спецификации для стандартных функций mem* • Добавлены лемма функции в язык ACSL • … Проект AstraVer. Доработка Frama-C/Jessie под работу с кодом Linux 

Заголовок 21 • Планирование • Назначение приоритетов верификации (критичности участков кода) • Продвижение верификации от вызываемых функций к вызывающим • Цикл верификации (модульная верификация) • Выделение функции со всеми зависимостями компиляции в отдельный файл (автоматизировано) • Разработка формальной спецификации ACSL • Доказательство соответствия между спецификацией и реализацией • Исправление кода (ошибки, адаптация под формальную верификацию) • Pull Request в общий репозиторий с кодом и спецификациями • Переверификация всех доказанных функций (CI) • Другие функции могут прямо/косвенно взаимодействовать с только что доказанной • Обновление глобальных спецификаций (новые леммы, уточнения общих предикатов, и т.д.) Рабочий процесс формальной верификации кода Linux (1) 

Заголовок 22 • Модуль ядра постоянно развивается • Нужно поддерживать спецификации в актуальном состоянии • Спецификации переписывались по меньшей мере 3 раза полностью • Переверификация всей системы в CI • Отдельная функция/группа схожих функций последовательно передоказываются • Цикл проверки доказательств занимает 6-7 часов (на Intel Core i7-7700, 32GB) • Максимальная автоматизация доказательств • Авто-активная верификация (лемма функции) • Стратегии трансформации условий верификаций и запуска солверов с различными настройками • Проверка противоречий • Трансформация условия верификации (доказательство цели и её отрицания) • //@ assert 0 == 1; Рабочий процесс формальной верификации кода Linux (2) 

Заголовок 23 Карта планирования/приоритетов формальной верификации демонстрация https://youtu.be/AuUsaleib9M 

Заголовок 24 Выделение отдельных функций из кода ядра/Перенос спецификаций SELinux Callgraph sel_netport_sid_slow function Extraction Transfer демонстрация https://asciinema.org/a/186080 

Заголовок 25 Отчетность. Статус работ по формальной верификации 

Заголовок 26 • Отдельные заголовочные файлы с теориями (предикаты, леммы, логические функции и т.д.) • Контракты спецификаций в заголовочных файлах с декларациями функций • Assertions и инварианты на циклы в теле функций • Примерно 2.6 строк спецификаций на одну строку С • Десятки тысяч условий верификации Результаты. Интеграция спецификаций в исходный код проекта 

Заголовок 27 • Не может быть доказана формальным образом • Проблемы: • Разные нотации/разные уровни абстракции • Модель описывает всю систему/механизм защиты – лишь часть системы • Реализация соответствует лишь части модели • Разработка Event-B/ACSL/C таким образом, чтобы связь между ними была легко отслеживаемой: • Verification-Driven Refactoring для Event-B/ACSL/C • Одинаковые имена предикаты в спецификациях Event-B/ACSL • Специальные логические типы в ACSL для отображения реализационных сущностей на Event-B абстракции • Implementation-To-Model (i2m) слой функций/предикатов в ACSL • Четкое разделение между требованиями уровня реализации и требованиями с модели Event-B на уровне ACSL спецификаций Результаты. Связь между моделью и реализацией Event-B ACSL C Event-B’ ACSL’ C’ 

Заголовок 28 • Государственная сертификация • Высокоуровневая модель системы контроля доступа на Event-B • Система контроля доступа в виде LSM модуля (аналог SELinux, AppArmor, Tomoyo …) • Реализует модуль ядра Linux с закрытым исходным кодом • Размер < 6.000 SLOC • Разработка спецификаций модели Event-B • Доказательство непротиворечивости • Доказательство выполнения инвариантов безопасности на модели • Разработка спецификаций ACSL на реализацию • Динамическая проверка соответствия реализации системы контроля доступа в виде LSM модуля модели Event-B Верификация модуля контроля доступа «Эльбрус-Д» 

Заголовок 29 • Большой объем кода • Частые обновления кода как ядра Linux, так и модуля безопасности (повторяемость проверки) Проверка наблюдаемого поведения ОС на соответствие модели Event-B: • Отслеживание системных вызовов (и иных операций внутри ядра) • Воспроизведение системного вызова на модели Event-B • Сверка результатов выполнения (разрешенных доступов) системных вызовов на модели и в реальной системе • Отслеживание покрытия по спецификации Even-B/коду ядра Почему динамическая проверка 

Заголовок 30 ● Уточнение (refinement) спецификаций Event-B c описанием системных вызовов ● Требования безопасности передоказываются на этом уровне уточнения ● В модели отсутствует понятия физических ресурсов машины, аппаратных сбоев ● Типы отслеживаемых ошибок: ● Пропущенный вызов модуля контроля доступа ● Неполнота LSM интерфейса ● Логическая ошибка в модуле контроля доступа Добавление системных вызовов в модель Event-B 

Заголовок 31 Воспроизведение системных вызовов на модели Event-B Ядро Linux LSM Модуль Аниматор ProB Сравнение Трансляция трасс системных вызовов Tests, Fuzzing, User + Fault Injection Модель Event-B Начальное окружение Трассы системных вызовов: • Kprobes/Kretprobes для мониторинга • Netlink для общения с userspace демоном • Kernel + LSM • GCOV для измерения покрытия Воспроизведение: • Трасса транслируется в модельную • Анимация модели в ProB • Ошибки: модель запрещает доступ, ядро разрешает • Покрытие по предусловиям модельных операций 

Заголовок 32 Сравнение результатов (1) +System +Model ● Принять, Продолжить -System -Model ● Принять, Продолжить 

Заголовок 33 Сравнение результатов (2) +System +Model ● Принять, Продолжить -System -Model ● Принять, Продолжить +System -Model ● Остановка, Ошибка 

Заголовок 34 Сравнение результатов (3) +System +Model ● Принять, Продолжить -System +Model ● Проверить код возврата ● Откатить, Продолжить -System -Model ● Принять, Продолжить +System -Model ● Остановка, Ошибка 

Заголовок 35 Требования сертификаций будут уточняться и усиливаться: • Требуются примеры успешных проектов • Формальная верификация исходного кода • Верификация реализации на соответствие высокоуровневой модели • Формальная верификация бинарного кода • … Формальная верификация С кода имеет смысл если: • Изначально разрабатывается под формальную верификацию • Проект тестируется на сборку в разных конфигурациях • Исправлены предупреждения компиляторов • Исправлены предупреждения статических анализаторов • Проект тестируется фаззингом с санитайзерами • Код проекта следует хотя бы части пунктов стандартов (MISRA,CEI CERT, …) Практические выводы (очевидные, но болезненные) 

Заголовок 36 • Разработчики получают пользу от “хороших” спецификаций • Формальный контракт может быть читабельнее и понятнее документации • Могут сами написать отдельные предусловия для функции • Если готова библиотека стандартных предикатов • Это уже делается в коде в виде assert, расстановки меток для стат. анализаторов • Код приходится менять под спецификации • Сложно написать хорошую и читабельную спецификацию на нечитабельный код • Из-за ограничений инструментов верификации иногда код проще переписать (зачастую найдутся пункты MISRA которому этот код не удовлетворяет) • Трюки с побитовой арифметикой, ассемблерные вставки для ускорения • Логически “нестройный” код ведет к таким же спецификациям и доказательствам • Все хотят чтобы разработчики инструментов находились рядом Практические выводы (менее очевидные) 

Заголовок 37 Практические выводы (неочевидные) Было: архитектура, разработка, тесты, релизы разработка и доказательство спецификаций Код Критичные ошибки Спецификации отдельно от кода Разработчики Спецификаторы 

Заголовок 38 Практические выводы (неочевидные) Было: архитектура, разработка, тесты, релизы разработка и доказательство спецификаций Код Критичные ошибки Спецификации отдельно от кода Протоколы ошибки, архитектура Стало: Будет: совместная команда Разработчики Спецификаторы архитектура, разработка, тесты, релизы разработка и доказательство спецификаций Код 

Заголовок 39 !! Заполнять форму необходимо после прослушивания всех интересующих вас докладов трека безопасной разработки https://forms.gle/5K3hPkMorvdJeY3a9 Пожалуйста, оцените этот доклад 

Заголовок ptsecurity.com Спасибо! Спасибо!