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. https://standoff365.com/phdays10/schedule/development/formal-verification-of-operating-system-kernels

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
Спасибо!
Спасибо!