Formal verification of operating system kernels

The speaker will share his experience of participating in projects on formal verification and analysis of access control modules for Astra Linux SE and Elbrus kernels, as well as verification of the Contiki code (OS for IoT) within the European VESSEDIA program. The speaker will disclose details about the development of formal access control models (Rodin/Event-B) and code specifications (Frama-C/ACSL), the use of static and dynamic analyzers, and the inclusion of formal analysis in the continuous integration cycle (continuous verification). Other types of work that help meet the certification requirements will also be considered.

Transcript

1. Заголовок ptsecurity.com Формальная верификация ядер операционных систем Денис Ефремов efremov@ispras.ru
2. Заголовок 2 • Научный сотрудник ИСП РАН (efremov@ispras.ru) • Занимался проектами формальной верификации/аудита кода ядра Linux с 2014 года • Поддерживаю floppy драйвер в ядре Linux • Готовлю ядро CruelKernel для телефонов Samsung S10/Note10 • Разработчик в команде KSPLICE подготовки исправлений безопасности для ядра Linux без перезагрузки О докладчике, опыте работы с Linux
3. Заголовок 3 https://app.sli.do/event/wv81wshd или https://www.sli.do/ Код: phdays10_development Задавайте вопросы онлайн
4. Заголовок 4 • Спецификация - набор требований и параметров, которым удовлетворяет некоторый объект (представлена в виде мат. модели, тестовых наборов, формальной спецификации); • Верификация - проверка соответствия программного обеспечения предъявляемым к нему требованиям; • Дедуктивная верификация – представление корректности программы как набора математических утверждений, называемых условиями верификации, выполнение которых проверяется автоматическими или интерактивными доказателями теорем. Верификация
5. Заголовок 5 • Компилятор и линковщик работают корректным образом • В программном обеспечении, использующемся при верификации, нет ошибок • Компьютер функционирует таким образом, как мы думаем об этом (rowhammer, spectre/meltdown, DMA) • Нижележащий слой ПО (например, ОС, прошивка сетевой карты, микрокод процессора) функционирует в рамках нашего представления о том, что он должен делать и чего делать не должен • Пользователь компьютера, если он есть, специально не «пакостит» • Выполнены формальные предположения о входных данных программы, начальном состоянии, поведении окружения • … На что опираться vs Что вы будете с этого иметь (1)
6. Заголовок 6 Гарантии того, что программное обеспечение функционирует в точном соответствии с требованиями, к нему предъявляемыми, на всех входных данных, начальных состояниях, при любом поведении окружения * ** * В предположении что все предположения выполнены ** И не осталось предположений, которых мы не занесли в списочек На что опираться vs Что вы будете с этого иметь (2)
7. Заголовок 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. Заголовок 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. Заголовок 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. Заголовок 10 /*@ requires b != 0; ensures a – a % b == b * \result; */ int div(int a, int b) { return a / b; } Фреймворк Frama-C. Язык спецификаций ACSL (1)
11. Заголовок 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. Заголовок 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. Заголовок 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. Заголовок 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. Заголовок 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. Заголовок 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. Заголовок 17 Формальная модель системы защиты. Спецификация Event-B https://github.com/17451k/base-model/blob/master/base-model.txt
18. Приложение/Процесс Проверка Аргументов (базовая валидация) Дискреционное Управление Доступом (DAC) Вызов LSM Структуры Данных/Ресурсы Linux Security Module (SELinux, AppArmor, и др.) Разрешить доступ в соответствии с моделью безопасности? Приложения Ядро Linux Результаты системного вызова Системный вызов Аргументы корректны DAC разрешен LSM разрешен Доступ запрещен Да/Нет
19. Заголовок 19 • Размер модуля < 5 KSLOC • +400 KSLOC из подключаемых заголовочных файлов (менее 100 KSLOC из них важны при компиляции) • Занимает ~20 минут только для того чтобы запустить инструменты Frama-C и сгенерировать условия верификации • Чем с большим количеством кода приходится работать одновременно, тем хуже происходит анализ/доказательство • Контракты для вызываемых из модуля функций ядра не доказываются • Соблюдение предусловий для функций модуля защиты не доказывается в точках их вызова ядром Работа с кодом ядра Linux
20. Заголовок 20 • Поддержка container_of • Поддержка указателей на функции • Полная переработка моделирования побитовых операций • Поддержка переинтерпретации указателей на целочисленные типы • Поддержка массивов нулевого размера, flexible arrays • Поддержка string literals • Добавлены шаблонные спецификации для стандартных функций mem* • Добавлены лемма функции в язык ACSL • … Проект AstraVer. Доработка Frama-C/Jessie под работу с кодом Linux
21. Заголовок 21 • Планирование • Назначение приоритетов верификации (критичности участков кода) • Продвижение верификации от вызываемых функций к вызывающим • Цикл верификации (модульная верификация) • Выделение функции со всеми зависимостями компиляции в отдельный файл (автоматизировано) • Разработка формальной спецификации ACSL • Доказательство соответствия между спецификацией и реализацией • Исправление кода (ошибки, адаптация под формальную верификацию) • Pull Request в общий репозиторий с кодом и спецификациями • Переверификация всех доказанных функций (CI) • Другие функции могут прямо/косвенно взаимодействовать с только что доказанной • Обновление глобальных спецификаций (новые леммы, уточнения общих предикатов, и т.д.) Рабочий процесс формальной верификации кода Linux (1)
22. Заголовок 22 • Модуль ядра постоянно развивается • Нужно поддерживать спецификации в актуальном состоянии • Спецификации переписывались по меньшей мере 3 раза полностью • Переверификация всей системы в CI • Отдельная функция/группа схожих функций последовательно передоказываются • Цикл проверки доказательств занимает 6-7 часов (на Intel Core i7-7700, 32GB) • Максимальная автоматизация доказательств • Авто-активная верификация (лемма функции) • Стратегии трансформации условий верификаций и запуска солверов с различными настройками • Проверка противоречий • Трансформация условия верификации (доказательство цели и её отрицания) • //@ assert 0 == 1; Рабочий процесс формальной верификации кода Linux (2)
23. Заголовок 23 Карта планирования/приоритетов формальной верификации демонстрация https://youtu.be/AuUsaleib9M
24. Заголовок 24 Выделение отдельных функций из кода ядра/Перенос спецификаций SELinux Callgraph sel_netport_sid_slow function Extraction Transfer демонстрация https://asciinema.org/a/186080
25. Заголовок 25 Отчетность. Статус работ по формальной верификации
26. Заголовок 26 • Отдельные заголовочные файлы с теориями (предикаты, леммы, логические функции и т.д.) • Контракты спецификаций в заголовочных файлах с декларациями функций • Assertions и инварианты на циклы в теле функций • Примерно 2.6 строк спецификаций на одну строку С • Десятки тысяч условий верификации Результаты. Интеграция спецификаций в исходный код проекта
27. Заголовок 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. Заголовок 28 • Государственная сертификация • Высокоуровневая модель системы контроля доступа на Event-B • Система контроля доступа в виде LSM модуля (аналог SELinux, AppArmor, Tomoyo …) • Реализует модуль ядра Linux с закрытым исходным кодом • Размер < 6.000 SLOC • Разработка спецификаций модели Event-B • Доказательство непротиворечивости • Доказательство выполнения инвариантов безопасности на модели • Разработка спецификаций ACSL на реализацию • Динамическая проверка соответствия реализации системы контроля доступа в виде LSM модуля модели Event-B Верификация модуля контроля доступа «Эльбрус-Д»
29. Заголовок 29 • Большой объем кода • Частые обновления кода как ядра Linux, так и модуля безопасности (повторяемость проверки) Проверка наблюдаемого поведения ОС на соответствие модели Event-B: • Отслеживание системных вызовов (и иных операций внутри ядра) • Воспроизведение системного вызова на модели Event-B • Сверка результатов выполнения (разрешенных доступов) системных вызовов на модели и в реальной системе • Отслеживание покрытия по спецификации Even-B/коду ядра Почему динамическая проверка
30. Заголовок 30 • Уточнение (refinement) спецификаций Event-B c описанием системных вызовов • Требования безопасности передоказываются на этом уровне уточнения • В модели отсутствует понятия физических ресурсов машины, аппаратных сбоев • Типы отслеживаемых ошибок: • Пропущенный вызов модуля контроля доступа • Неполнота LSM интерфейса • Логическая ошибка в модуле контроля доступа Добавление системных вызовов в модель Event-B
31. Заголовок 31 Воспроизведение системных вызовов на модели Event-B Ядро Linux LSM Модуль Аниматор ProB Сравнение Трансляция трасс системных вызовов Tests, Fuzzing, User + Fault Injection Модель Event-B Начальное окружение Трассы системных вызовов: • Kprobes/Kretprobes для мониторинга • Netlink для общения с userspace демоном • Kernel + LSM • GCOV для измерения покрытия Воспроизведение: • Трасса транслируется в модельную • Анимация модели в ProB • Ошибки: модель запрещает доступ, ядро разрешает • Покрытие по предусловиям модельных операций
32. Заголовок 32 Сравнение результатов (1) +System +Model • Принять, Продолжить -System -Model • Принять, Продолжить
33. Заголовок 33 Сравнение результатов (2) +System +Model • Принять, Продолжить -System -Model • Принять, Продолжить +System -Model • Остановка, Ошибка
34. Заголовок 34 Сравнение результатов (3) +System +Model • Принять, Продолжить -System +Model • Проверить код возврата • Откатить, Продолжить -System -Model • Принять, Продолжить +System -Model • Остановка, Ошибка
35. Заголовок 35 Требования сертификаций будут уточняться и усиливаться: • Требуются примеры успешных проектов • Формальная верификация исходного кода • Верификация реализации на соответствие высокоуровневой модели • Формальная верификация бинарного кода • … Формальная верификация С кода имеет смысл если: • Изначально разрабатывается под формальную верификацию • Проект тестируется на сборку в разных конфигурациях • Исправлены предупреждения компиляторов • Исправлены предупреждения статических анализаторов • Проект тестируется фаззингом с санитайзерами • Код проекта следует хотя бы части пунктов стандартов (MISRA,CEI CERT, …) Практические выводы (очевидные, но болезненные)
36. Заголовок 36 • Разработчики получают пользу от “хороших” спецификаций • Формальный контракт может быть читабельнее и понятнее документации • Могут сами написать отдельные предусловия для функции • Если готова библиотека стандартных предикатов • Это уже делается в коде в виде assert, расстановки меток для стат. анализаторов • Код приходится менять под спецификации • Сложно написать хорошую и читабельную спецификацию на нечитабельный код • Из-за ограничений инструментов верификации иногда код проще переписать (зачастую найдутся пункты MISRA которому этот код не удовлетворяет) • Трюки с побитовой арифметикой, ассемблерные вставки для ускорения • Логически “нестройный” код ведет к таким же спецификациям и доказательствам • Все хотят чтобы разработчики инструментов находились рядом Практические выводы (менее очевидные)
37. Заголовок 37 Практические выводы (неочевидные) Было: архитектура, разработка, тесты, релизы разработка и доказательство спецификаций Код Критичные ошибки Спецификации отдельно от кода Разработчики Спецификаторы
38. Заголовок 38 Практические выводы (неочевидные) Было: архитектура, разработка, тесты, релизы разработка и доказательство спецификаций Код Критичные ошибки Спецификации отдельно от кода Протоколы ошибки, архитектура Стало: Будет: совместная команда Разработчики Спецификаторы архитектура, разработка, тесты, релизы разработка и доказательство спецификаций Код
39. Заголовок 39 !! Заполнять форму необходимо после прослушивания всех интересующих вас докладов трека безопасной разработки https://forms.gle/5K3hPkMorvdJeY3a9 Пожалуйста, оцените этот доклад
40. Заголовок ptsecurity.com Спасибо! Спасибо!