Доклад посвящен разработке корректного программного обеспечения с применением одного из видов статического анализа кода. Будут освещены вопросы применения подобных методов, их слабые стороны и ограничения, а также рассмотрены результаты, которые они могут дать. На конкретных примерах будет продемонстрировано, как выглядят разработка спецификаций для кода на языке Си и доказательство соответствия кода спецификациям.
Approof — статический анализатор кода для проверки веб-приложений на наличие уязвимых компонентов. В своей работе анализатор основывается на правилах, хранящих сигнатуры искомых компонентов. В докладе рассматривается базовая структура правила для Approof и процесс автоматизации его создания.
Доклад посвящен разработке корректного программного обеспечения с применением одного из видов статического анализа кода. Будут освещены вопросы применения подобных методов, их слабые стороны и ограничения, а также рассмотрены результаты, которые они могут дать. На конкретных примерах будет продемонстрировано, как выглядят разработка спецификаций для кода на языке Си и доказательство соответствия кода спецификациям.
Approof — статический анализатор кода для проверки веб-приложений на наличие уязвимых компонентов. В своей работе анализатор основывается на правилах, хранящих сигнатуры искомых компонентов. В докладе рассматривается базовая структура правила для Approof и процесс автоматизации его создания.
Выступление Дениса Колегова, посвященное методам защиты веб-приложений, применяемым в межсетевых экранах, на встрече PDUG Meetup: J'adore hardcore 20 декабря 2016 года.
Оптимизация высоконагруженных ASP.NET приложений, работающих с MS SQL Server ...Stas Vyschepan
Вы разрабатываете веб-приложения и используете хранимые процедуры? Вы пишите SELECT … WITH(NOLOCK)? Вы считаете, что ORMы снижают быстродействие приложений? Тогда этот доклад для вас!
В докладе будут развенчаны популярные мифы о применении библиотек Object-Relational Mapping (ORM) в ASP.NET при работе с Microsoft SQL Server. Также будут рассмотрены конкретные методики увеличения быстродействия работы с данными в веб-приложениях.
От экспериментального программирования к промышленному: путь длиной в 10 летPositive Hack Days
Разработка наукоемкого программного обеспечения отличается тем, что нет ни четкой постановки задачи, ни понимания, что получится в результате. Однако даже этом надо программировать то, что надо, и как надо. Докладчик расскажет о том, как ее команда успешно разработала и вывела в промышленную эксплуатацию несколько наукоемких продуктов, пройдя непростой путь от эксперимента, результатом которого был прототип, до промышленных версий, которые успешно продаются как на российском, так и на зарубежном рынках. Этот путь был насыщен сложностями и качественными управленческими решениями, которыми поделится докладчик
Formal Verification of a Linux Security ModuleDenis Efremov
Формальная верификация модуля безопасности Linux. Презентация про проект AstraVer ИСП РАН. Доклад представлен на сессии коротких докладов летней школы Мастерчейн. НИУ ВШЭ, Москва, 09 июля 2018.
SAST, CWE, SEI CERT и другие умные слова из мира информационной безопасностиAndrey Karpov
Поговорим о таких терминах, связанных с информационной безопасностью, как SAST, CWE, CVE, SEI CERT, DevSecOps и как они между собой связаны. Доклад ориентирован на разработчиков и знакомит их с некоторыми понятиями и стандартами кодирования, помогающими создавать надежные, безопасные приложения. Другими словами, как писать код с меньшим количеством потенциальных уязвимостей.
Выступление Дениса Колегова, посвященное методам защиты веб-приложений, применяемым в межсетевых экранах, на встрече PDUG Meetup: J'adore hardcore 20 декабря 2016 года.
Оптимизация высоконагруженных ASP.NET приложений, работающих с MS SQL Server ...Stas Vyschepan
Вы разрабатываете веб-приложения и используете хранимые процедуры? Вы пишите SELECT … WITH(NOLOCK)? Вы считаете, что ORMы снижают быстродействие приложений? Тогда этот доклад для вас!
В докладе будут развенчаны популярные мифы о применении библиотек Object-Relational Mapping (ORM) в ASP.NET при работе с Microsoft SQL Server. Также будут рассмотрены конкретные методики увеличения быстродействия работы с данными в веб-приложениях.
От экспериментального программирования к промышленному: путь длиной в 10 летPositive Hack Days
Разработка наукоемкого программного обеспечения отличается тем, что нет ни четкой постановки задачи, ни понимания, что получится в результате. Однако даже этом надо программировать то, что надо, и как надо. Докладчик расскажет о том, как ее команда успешно разработала и вывела в промышленную эксплуатацию несколько наукоемких продуктов, пройдя непростой путь от эксперимента, результатом которого был прототип, до промышленных версий, которые успешно продаются как на российском, так и на зарубежном рынках. Этот путь был насыщен сложностями и качественными управленческими решениями, которыми поделится докладчик
Formal Verification of a Linux Security ModuleDenis Efremov
Формальная верификация модуля безопасности Linux. Презентация про проект AstraVer ИСП РАН. Доклад представлен на сессии коротких докладов летней школы Мастерчейн. НИУ ВШЭ, Москва, 09 июля 2018.
SAST, CWE, SEI CERT и другие умные слова из мира информационной безопасностиAndrey Karpov
Поговорим о таких терминах, связанных с информационной безопасностью, как SAST, CWE, CVE, SEI CERT, DevSecOps и как они между собой связаны. Доклад ориентирован на разработчиков и знакомит их с некоторыми понятиями и стандартами кодирования, помогающими создавать надежные, безопасные приложения. Другими словами, как писать код с меньшим количеством потенциальных уязвимостей.
Formal verification of operating system kernelsDenis Efremov
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
Экстремальная оптимизация производительности на примере MongoDB Java DriverVitebsk DSC
При работе с базами данных мы часто сталкиваемся с тем, что ORM фреймворки, принося нам удобство и гибкость, требуют непомерную плату – серьезное падение производительности. Казалось бы, чтобы решить эту проблему, достаточно просто отказаться от ORM и использовать низкоуровневый API. Но иногда и этого бывает недостаточно…
Презентация подготовлена по материалам выступления Евгения Берлога на витебской конференции “Developer's Software Conference” (31.10.2015). Запись выступления: https://events.epam.com/events/dsc2015/talks/104.
Статический анализ кода: борьба с удорожанием ошибокAndrey Karpov
Нет смысла говорить, что "надо писать код без ошибок". Ошибки были, есть и будут. Все хорошо понимают, что ошибки следует исправлять. Люди забывают, что ошибка должна быть исправлена с минимальными временными и денежными затратами!
This talk about how android developers can use sun.misc.Unsafe for boost their app speed with direct access to sandbox memory and to understand how android allocates memory and works with serialization, concurrency and reflection.
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...yaevents
Александр Петренко, ИСП РАН
Профессор, доктор физико-математических наук, заведующий отделом технологий программирования Института системного программирования (ИСП РАН), профессор ВМК МГУ. Основные работы в областях: формализация требований, генерация тестов на основе формализованных требований и формальных моделей (model based testing – MBT). Приложения: тестирование операционных систем и распределенных систем, тестирование компиляторов, верификация дизайна микропроцессоров, формализация стандартов на API операционных систем и телекоммуникационных протоколов. Сопредседатель оргкомитетов International MBT workshop (http://www.mbrworkshop.org/), Spring Young Researcher Colloquium on Software Engineering – SYRCoSE (http://syrocose.ispras.ru), городского семинара по технологиям разработки и анализа программ ТРАП/SDAT (http://sdat.ispras.ru/).
Тема доклада
Модели в профессиональной инженерии и тестировании программ.
Тезисы
Model Based Software Engineering (MBSE) является расширением подхода к разработке программ на основе моделей. В MBSE в отличие, например, от MDA (Model Driver Architecture) существенное внимание уделяется не только задачам собственно проектирования и разработки кода, но и задачам других фаз жизненного цикла – анализу требований, верификации и валидации, управлению требованиями на всех фазах жизненного цикла. Model Based Testing (MBT) хронологически возник гораздо раньше, чем MBSE и MDA, однако его место в разработке программ в полной мере раскрылось вместе с развитием MBSE. По этой причине MBT и MBSE следует рассматривать в тесной связке. В докладе будут рассмотрены концепции MBSE-MDA-MBT, основные источники и виды моделей, которые используются в этих подходах, методы генерации тестов на основе моделей, известные инструменты для
В презентации рассказывается о структурах памяти в JVM: Heap, Non-Heap, Stack, об атомарности операций и о garbage collector. Рассмотрен пример, как работает стек. Также, приведены примеры, как использовать jVisualVM и что она может показать.
Tech Talks @NSU: Как приручить дракона: введение в LLVMTech Talks @NSU
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=v7uBLSm6ft8
06 октября 2015. Как приручить дракона: введение в LLVM (Дмитрий Кашицын, HDsoft)
«В этом докладе мы кратко расскажем о таком звере, о котором много кто слышал, но немногие щупали. Что такое компилятор на самом деле? Чем LLVM отличается от других компиляторов? Как в LLVM происходит компиляция программы, как работают оптимизации? Наконец, какой путь проходит программа от разбора исходного текста до генерации исполняемого файла?
Лекция будет обзорной и не потребует от слушателей глубоких знаний теории компиляторов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
10 июня 2015. Дмитрий Кашицын (HDsoft) дает обзор LLVM.
http://techtalks.nsu.ru
Видеозапись: https://plus.google.com/events/ctes98f7uhf19t5jlvlbk24dan4
В этом докладе мы кратко расскажем о таком звере, как LLVM, о котором много кто слышал, но немногие щупали. Что такое компилятор на самом деле? Чем LLVM отличается от других компиляторов? Как в LLVM происходит компиляция программы, как работают оптимизации? Наконец, какой путь проходит программа от разбора исходного текста до генерации исполняемого файла?
Лекция будет обзорной и не потребует от слушателей глубоких знаний теории компиляторов.
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Многие разработчики не представляют, как дорого обходятся ошибки в программах. Причем я имею в виду не падения ракет и прочие катастрофы, а обыкновенное прикладное программное обеспечение. Хочется показать всю важность нахождения ошибок на самых ранних этапах. Одним из способов выявить ошибку как можно раньше является статический анализ кода. Поговорим мы не только об этом, но и о различных приемах при написании кода, которые позволят избежать множество типовых ошибок.
Поиск уязвимостей с использованием статического анализа кодаcorehard_by
Поиск уязвимостей с использованием статического анализа кода, Андрей Карпов и Евгений Рыжков
В последнее время мы все слышим о новых и новых уязвимостях, обнаруженных в программном обеспечении. Уже стало очевидно, что писать код без уязвимостей человечество не может. Но могут ли современные инструменты разработки помочь обнаружить хотя бы некоторые ошибки? В докладе НЕ будет фраз типа «купите такой-то инструмент, чтобы не допускать уязвимостей в своем и чужом коде». На реальных примерах мы попробуем показать какие типы уязвимостей или по-другому программных дефектов могут быть найдены с помощью технологий анализа кода, а какие – пока нет. Ну и конечно как писать код так, чтобы снизить вероятность появления уязвимостей в своем коде.
Поиск уязвимостей с использованием статического анализа кодаAndrey Karpov
Уязвимости - это те же самые обыкновенные ошибки. Зачем их выделять? Делайте это, если хотите заработать больше денег. CWE - Common Weakness Enumeration. CVE - Common Vulnerabilities and Exposures. Теперь с помощью Valgrind вы ищете не утечку памяти, а отказ в обслуживании!
Как команда PVS-Studio может улучшить код операционной системы TizenAndrey Karpov
Цель: Контрактная работа команды PVS-Studio по исправлению ошибок и регулярному аудиту кода. Сейчас анализатор PVS-Studio выявляет более 10% ошибок, которые присутствуют в коде проекта Tizen. В случае регулярного использования PVS-Studio, в новом коде можно будет предотвратить около 20% ошибок.
Я прогнозирую, что команда PVS-Studio может на данный момент выявить и исправить около 27000 ошибок в проекте Tizen.
2. Заголовок
• Hacker-Proof Code Confirmed (quantamagazine)
• Computer Scientists Close In on Perfect, Hack-Proof Code (wired)
• Kaspersky Launches ‘Unhackable’ OS (guidingtech)
• Unhackable kernel could keep all computers safe from cyberattack
(newscientist)
• Is This Security-Focused Linux Kernel Really UnHackable?
(thehackernews)
• Hack-resilient
• Error-free code
• Yale develops world's first hacker-resistant operating system
(ibtimes)
Немного заголовков
3. Заголовок
• Crowd Sourced Formal Verification (CSFV) (VERIGAMES)
• High-Assurance Cyber Military Systems (HACMS)
• Formally Verify Blockchain-Based Integrity Monitoring System
• A Diagnostic Approach for Persistent Threat Detection (ADAPT)
• Cyber Fault-tolerant Attack Recovery (CFAR)
• Testing and Modeling of Brandeis Artifacts (TAMBA)
• Clean-slate design of Resilient, Adaptive, Secure Hosts (CRASH)
DARPA
4. Заголовок
• 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 «Требованиях
безопасности информации к операционным системам» профили
защиты операционных систем общего назначения (типа «А»)
Стандарты
6. Заголовок
• Верификация - проверка соответствия программного
обеспечения предъявляемым к нему требованиям;
• Дедуктивная верификация – представление
корректности программы как набора математических
утверждений, называемых условиями верификации,
выполнение которых проверяется автоматическими или
интерактивными доказателями теорем;
• Спецификация - набор требований и параметров,
которым удовлетворяет некоторый объект
(представлена в виде мат. модели, тестовых наборов,
формальной спецификации)
Верификация
7. Заголовок
Высшая школа экономики, Москва, 2016
Дедуктивная верификация программ
• Лекция Алана Тьюринга Лондонскому математическому
обществу
• Методы Флойда/Хоара
• Инструменты дедуктивной верификации для Си, Java, С#
• SunRise, ESC/Java, Frama-C, LOOP, Boogie/VCC
• Применение к реальным проектам небольшого размера
• Атомная энергетика (Англия, Франция)
• Авионика (Airbus, NASA)
• Компоненты специализированных ОС (seL4, Hyper-V)
8. Заголовок
• Компилятор и линковщик работают корректным образом
• В программном обеспечении, использующемся при верификации, не
произошло ошибок
• Компьютер функционирует таким образом, как мы думаем об этом
(rowhammer)
• Нижележащий слой ПО (например, ОС, прошивка сетевой карты,
микрокод процессора) функционирует в рамках нашего
представления о том, что он должен делать и что не должен делать
(и ещё не содержит ошибок)
• Пользователь компьютера, если он есть, специально не «пакостит»
• Выполнены предположения о входных данных программы, о
начальном состоянии
• …
На что опираться vs. Что вы будете с этого иметь (1)
9. Заголовок
•Гарантии того, что программное
обеспечение функционирует в точном
соответствии с требованиями, к нему
предъявляемыми, на всех входных
данных, начальных состояниях, при
любом поведении окружения * **
• * В предположении что все предположения выполнены
• ** И не осталось предположений, которых мы не занесли в списочек
На что опираться vs. Что вы будете с этого иметь (2)
15. Заголовок
• Массив отсортирован
∀𝑖𝑛𝑡 𝑗; 0 ≤ 𝑗 < 𝐴𝑅𝑅𝐴𝑌_𝑆𝐼𝑍𝐸 − 1 ⇒ 𝑎 𝑗 ≤ 𝑎[𝑗 + 1]
• Функция возвращает всегда положительное значение
𝑟𝑒𝑠𝑢𝑙𝑡 > 0
Примеры требований по функциональности
16. Заголовок
• Массив отсортирован
∀𝑖𝑛𝑡 𝑗; 0 ≤ 𝑗 < 𝐴𝑅𝑅𝐴𝑌_𝑆𝐼𝑍𝐸 − 1 ⇒ 𝑎 𝑗 ≤ 𝑎[𝑗 + 1]
• Функция возвращает всегда положительное значение
𝑟𝑒𝑠𝑢𝑙𝑡 > 0
• Функция может менять порядок элементов в массиве, но
не его содержимое 0_0
Примеры требований по функциональности
17. Заголовок
• Массив отсортирован
∀𝑖𝑛𝑡 𝑗; 0 ≤ 𝑗 < 𝐴𝑅𝑅𝐴𝑌_𝑆𝐼𝑍𝐸 − 1 ⇒ 𝑎 𝑗 ≤ 𝑎[𝑗 + 1]
• Функция возвращает всегда положительное значение
𝑟𝑒𝑠𝑢𝑙𝑡 > 0
• Функция может менять порядок элементов в массиве, но
не его содержимое 0_0
• Если в дереве присутствует искомый элемент, то
функциях его обязательно найдёт O_O
Примеры требований по функциональности
18. Заголовок
• Массив отсортирован
∀𝑖𝑛𝑡 𝑗; 0 ≤ 𝑗 < 𝐴𝑅𝑅𝐴𝑌_𝑆𝐼𝑍𝐸 − 1 ⇒ 𝑎 𝑗 ≤ 𝑎[𝑗 + 1]
• Функция возвращает всегда положительное значение
𝑟𝑒𝑠𝑢𝑙𝑡 > 0
• Функция может менять порядок элементов в массиве, но
не его содержимое 0_0
• Если в дереве присутствует искомый элемент, то
функциях его обязательно найдёт O_O
• Программа не держит в памяти секретные данные
дольше, чем это требуется для их обработки @_@
• …
Примеры требований по функциональности
19. Заголовок
• CompCert – компилятор языка Clight (Coq > Ocaml)
• seL4 – микроядро L4 (Cparse > Isabelle/HOL)
• CertiKOS – Certified Kit Operating System
• Ironclad – End-to-End Security via Automated Full-
System Verification (Dafny)
• FSCQ – A Formally Certified Crash-proof File System (Coq)
• Quark – веб-браузер с верифицированным ядром (Coq)
Известные проекты
20. Заголовок
Высшая школа экономики, Москва, 2016
Что можно сказать о функции на языке Си по её коду? (1)
• Она существует и написана на языке Си;
21. Заголовок
Высшая школа экономики, Москва, 2016
Что можно сказать о функции на языке Си по её коду? (1)
• Она существует и написана на языке Си;
• Это чистая функция;
• Она вычисляет среднее между двумя целыми числами;
22. Заголовок
Высшая школа экономики, Москва, 2016
Что можно сказать о функции на языке Си по её коду? (1)
• Она существует и написана на языке Си;
• Это чистая функция;
• Она вычисляет среднее между двумя целыми числами;
• При определённых условиях возможно целочисленное переполнение.
23. Заголовок
Высшая школа экономики, Москва, 2016
Что можно сказать о функции на языке Си по её коду? (2)
• Возможно ли целочисленное переполнение в том контексте,
где функция вызывается?
• Считать ли возможное целочисленное переполнение
ошибкой?
24. Заголовок
Высшая школа экономики, Москва, 2016
Что можно сказать о функции на языке Си по её коду? (3)
• Контекст: функция двоичного
поиска;
• Индексы l и h неотрицательны,
l не превосходит h;
• Возможна ошибка выхода за
границу массива при
целочисленном
переполнении.
25. Заголовок
Высшая школа экономики, Москва, 2016
Как доказать что код функции корректен? (1)
•Описать контекст вызова:
𝜙: 𝑍 × 𝑍 → ⊤, ⊥
𝜙 𝑎, 𝑏 ≡ 𝑎 ≥ 0 ∧ 𝑏 ≥ 0 ∧ 𝑎 ≤ 𝑏
26. Заголовок
Высшая школа экономики, Москва, 2016
Как доказать что код функции корректен? (1)
•Описать контекст вызова:
𝜙: 𝑍 × 𝑍 → ⊤, ⊥
𝜙 𝑎, 𝑏 ≡ 𝑎 ≥ 0 ∧ 𝑏 ≥ 0 ∧ 𝑎 ≤ 𝑏
•Описать требования, которым должны
удовлетворять результаты:
𝜓: 𝑍 × 𝑍 × 𝑍 → {⊤, ⊥}
𝜓 𝑎, 𝑏, 𝑟𝑒𝑠𝑢𝑙𝑡 ≡ 𝑟𝑒𝑠𝑢𝑙𝑡 =
𝑎 + 𝑏
2
27. ЗаголовокКак доказать что код функции корректен? (2)
• Формализовать понятие ошибки (целочисленное
переполнение):
𝑖𝑛_𝑏𝑜𝑢𝑛𝑑𝑠: 𝑍 → {⊤, ⊥}
𝑖𝑛_𝑏𝑜𝑢𝑛𝑑𝑠 𝑛 ≡ 𝑀𝐼𝑁_𝐼𝑁𝑇 ≤ 𝑛 ≤ 𝑀𝐴𝑋_𝐼𝑁𝑇
28. ЗаголовокКак доказать что код функции корректен? (2)
• Формализовать понятие ошибки (целочисленное
переполнение):
𝑖𝑛_𝑏𝑜𝑢𝑛𝑑𝑠: 𝑍 → {⊤, ⊥}
𝑖𝑛_𝑏𝑜𝑢𝑛𝑑𝑠 𝑛 ≡ 𝑀𝐼𝑁_𝐼𝑁𝑇 ≤ 𝑛 ≤ 𝑀𝐴𝑋_𝐼𝑁𝑇
• Формализовать код программы: функция 𝑀 𝑎𝑣𝑟 , которая
возвращает результат 𝑀 𝑎𝑣𝑟 (𝑎, 𝑏) в соответствии со своим
программным кодом если завершается и завершается без
ошибки, иначе возвращается специальное значение 𝜔
29. Заголовок
Высшая школа экономики, Москва, 2016
Как доказать что код функции корректен? (2)
• Формализовать понятие ошибки (целочисленное
переполнение):
𝑖𝑛_𝑏𝑜𝑢𝑛𝑑𝑠: 𝑍 → {⊤, ⊥}
𝑖𝑛_𝑏𝑜𝑢𝑛𝑑𝑠 𝑛 ≡ 𝑀𝐼𝑁_𝐼𝑁𝑇 ≤ 𝑛 ≤ 𝑀𝐴𝑋_𝐼𝑁𝑇
• Формализовать код программы: функция 𝑀 𝑎𝑣𝑟 , которая
возвращает результат 𝑀 𝑎𝑣𝑟 (𝑎, 𝑏) в соответствии со своим
программным кодом если завершается и завершается без
ошибки, иначе возвращается специальное значение 𝜔
• Доказать полную корректность:
∀𝑎, 𝑏 𝜙 𝑎, 𝑏 ⇒ 𝑀 𝑎𝑣𝑟 𝑎, 𝑏 ≠ 𝜔 && 𝜓 𝑎, 𝑏, 𝑀 𝑎𝑣𝑟 𝑎, 𝑏
30. Заголовок
Высшая школа экономики, Москва, 2016
Как доказать что код функции корректен? (3)
function to_int bint : int
function of_int int : bint
31. Заголовок
Высшая школа экономики, Москва, 2016
Как доказать что код функции корректен? (3)
function to_int bint : int
function of_int int : bint
predicate in_bounds (n:int) = -2147483648 <= n && n <=
2147483647
32. Заголовок
Высшая школа экономики, Москва, 2016
Как доказать что код функции корректен? (3)
function to_int bint : int
function of_int int : bint
predicate in_bounds (n:int) = -2147483648 <= n && n <=
2147483647
constant a, b, o1, o2: bint
axiom H0: a >= of_int 0 && b >= of_int 0 && b >= a
33. Заголовок
Высшая школа экономики, Москва, 2016
Как доказать что код функции корректен? (3)
function to_int bint : int
function of_int int : bint
predicate in_bounds (n:int) = -2147483648 <= n && n <=
2147483647
constant a, b, o1, o2: bint
axiom H0: a >= of_int 0 && b >= of_int 0 && b >= a
axiom H1: to_int o1 = 2
axiom H2: to_int o2 = (to_int a + to_int b)
34. Заголовок
Высшая школа экономики, Москва, 2016
Как доказать что код функции корректен? (3)
function to_int bint : int
function of_int int : bint
predicate in_bounds (n:int) = -2147483648 <= n && n <=
2147483647
constant a, b, o1, o2: bint
axiom H0: a >= of_int 0 && b >= of_int 0 && b >= a
axiom H1: to_int o1 = 2
axiom H2: to_int o2 = (to_int a + to_int b)
goal avr_safety:
in_bounds 2 ->
35. Заголовок
Высшая школа экономики, Москва, 2016
Как доказать что код функции корректен? (3)
function to_int bint : int
function of_int int : bint
predicate in_bounds (n:int) = -2147483648 <= n && n <=
2147483647
constant a, b, o1, o2: bint
axiom H0: a >= of_int 0 && b >= of_int 0 && b >= a
axiom H1: to_int o1 = 2
axiom H2: to_int o2 = (to_int a + to_int b)
goal avr_safety:
in_bounds 2 ->
in_bounds(to_int a + to_int b) ->
36. Заголовок
Высшая школа экономики, Москва, 2016
Как доказать что код функции корректен? (3)
function to_int bint : int
function of_int int : bint
predicate in_bounds (n:int) = -2147483648 <= n && n <=
2147483647
constant a, b, o1, o2: bint
axiom H0: a >= of_int 0 && b >= of_int 0 && b >= a
axiom H1: to_int o1 = 2
axiom H2: to_int o2 = (to_int a + to_int b)
goal avr_safety:
in_bounds 2 ->
in_bounds(to_int a + to_int b) ->
not to_int o1 = 0 ->
37. Заголовок
Высшая школа экономики, Москва, 2016
Как доказать что код функции корректен? (3)
function to_int bint : int
function of_int int : bint
predicate in_bounds (n:int) = -2147483648 <= n && n <=
2147483647
constant a, b, o1, o2: bint
axiom H0: a >= of_int 0 && b >= of_int 0 && b >= a
axiom H1: to_int o1 = 2
axiom H2: to_int o2 = (to_int a + to_int b)
goal avr_safety:
in_bounds 2 ->
in_bounds(to_int a + to_int b) ->
not to_int o1 = 0 ->
in_bounds(div (to_int o2) (to_int o1))
41. Заголовок
Высшая школа экономики, Москва, 2016
Как доказать что код функции корректен? (4)
Условие верификации
Исправление кода
Уточнение спецификаций
43. Высшая школа экономики, Москва, 2016
Стек
инструментов
дедуктивной
верификации
CIL
CIL with annotations
С program with
ACSL annotations
Jessie program
(with annotations built-in)
Jessie translator
Why3 support
Jessie2
CIL
visitors (rewriters)
Frama-C
Jessie plugin
44. Высшая школа экономики, Москва, 2016
Стек
инструментов
дедуктивной
верификации
CIL
CIL with annotations
С program with
ACSL annotations
Jessie program
(with annotations built-in)
Jessie translator
Why3 support
Why3 VC generator
Why3 WhyML modules
Verification conditions
in Why3MLVC transformations
Why3 encoders + drivers
Logical formulas/scripts in
SMT-LIB/SMT-LIBv2/native format
Coq, PVS, Isabelle
proof templates
Why3
transformation/proof/shapes
database
Alt-Ergo Z3 CVC4 Coq PVS
Why3 IDE
...
Jessie2
CIL
visitors (rewriters)
Frama-C
Jessie plugin
Why3
Isabelle ...
45. Заголовок
• Код
• Что формальная верификация может проверить и чего не может?
• Формальные спецификации
• Можно ли разработать формальные спецификации до стадии
написания кода?
• Что в них должно быть отображено?
• Что инструмент (его модели и теоретическая основа) позволяет в них
отобразить?
• Насколько полными/точными/непротиворечивыми должны быть
спецификации?
• Код и спецификации
• Можно ли дважды ошибиться и при этом доказать, что всё корректно?
Где может встречаться ошибка?
46. Заголовок
• Зависит от того, какие модели заложены в инструментах
верификации
• Памяти, целочисленной арифметики, битовой арифметики…
• Чем сложнее модель, тем детальнее она отражает
действительность
• Чем сложнее модель, тем более сложными становятся формулы
условий верификации
• Чем сложнее формулы, тем хуже на них работают
автоматические доказатели логических формул
• Аналогия QEMU⟺BOCHS
Ошибки, которые «ловятся» в коде (1)
47. Заголовок
• Деление на ноль
• Разыменование указателя
• Некратный сдвиг типизированного указателя
• Выход за границу массива
• Целочисленное переполнение
• Переполнение при операциях с плавающей запятой
• Бесконечные циклы
• …
Ошибки, которые «ловятся» в коде (2)
48. Заголовок
•А как вы моделируете память (read, write)?
char *p = "побольше цинизма, Киса";
p[0] = 'П';
•А как вы моделируете указатели
(переполнение указателей)?
char *p = UINT_MAX - 1;
strlen(p);
Вопрос гарантии отсутствия ошибок в коде (ошибки, которые «не ловятся»)
49. Заголовок
•А как вы моделируете стек (ограниченный или
безграничный)?
#define STACK_SIZE 1000*0x1000
//@ ensures result == 1;
int main(void) {
int a[STACK_SIZE];
memset(a, 0, STACK_SIZE);
a[STACK_SIZE-1] = 1;
return a[STACK_SIZE-1];
}
Вопрос гарантии отсутствия ошибок в коде (ошибки, которые «не ловятся»)
50. Заголовок
•Что мы пишем в функциональные требования?
ensures result >= 0;
long abs(int a) { return 4; }
Ошибки, специфичные для спецификаций (полнота) (1)
51. Заголовок
•Что мы пишем в функциональные требования?
ensures result >= 0;
long abs(int a) { return 4; }
•Как мы пишем функциональные требования?
unsigned abs(int a)
return a >= 0 ? a :-((long)a);
ensures result == a || result == -a;
Ошибки, специфичные для спецификаций (полнота) (1)
52. Заголовок
•Что мы пишем в функциональные требования?
ensures result >= 0;
long abs(int a) { return 4; }
•Как мы пишем функциональные требования?
unsigned abs(int a)
return a >= 0 ? a :-((long)a);
ensures result == a || result == -a;
ensures result == -a <==> a < 0;
Ошибки, специфичные для спецификаций (полнота) (1)
53. Заголовок
•Что мы пишем в функциональные требования?
ensures result >= 0;
long abs(int a) { return 4; }
•Как мы пишем функциональные требования?
unsigned abs(int a)
return a >= 0 ? a :-((long)a);
ensures result == a || result == -a;
ensures result == -a <==> a < 0;
ensures a>=0 ? result==a : result==-a;
Ошибки, специфичные для спецификаций (полнота) (1)
54. Заголовок
• Какие свойства мы выражаем в требованиях?
requires n == 2 && valid(a+(0..n-1));
ensures forall integer i, j; 0 <= i < j < n ==>
a[i] <= a[j]; // отсортированность
void sort(size_t n, int a[n]) { a[0] = 1; a[1] = 2; }
Ошибки, специфичные для спецификаций (полнота) (2)
55. Заголовок
• Какие свойства мы выражаем в требованиях?
requires n == 2 && valid(a+(0..n-1));
ensures forall integer i, j; 0 <= i < j < n ==>
a[i] <= a[j]; // отсортированность
void sort(size_t n, int a[n]) { a[0] = 1; a[1] = 2; }
• Как правильно их выразить?
... //сохранение всех элементов
ensures forall int *i; a <= i < a + n ==>
Сount{Pre}(a, n, *i) == Сount{Post}(a, n, *i);
void sort(size_t n,int a[n]){if(a[0]>a[1])swap(a,0,1);}
Ошибки, специфичные для спецификаций (полнота) (2)
56. Заголовок
• Противоречие в логических утверждениях
a == 1 && a == 2
Ошибки, специфичные для спецификаций (противоречия) (1)
57. Заголовок
• Противоречие в логических утверждениях
a == 1 && a == 2
• Изо лжи следует всё, что угодно
requires 0 == 1;
ensures result == 0 && result == 1 &&
result == 2;
int main(void) { int a = 1; return a / 0; }
Ошибки, специфичные для спецификаций (противоречия) (1)
58. Заголовок
• Противоречие в логических утверждениях
a == 1 && a == 2
• Изо лжи следует всё, что угодно
requires 0 == 1;
ensures result == 0 && result == 1 &&
result == 2;
int main(void) { int a = 1; return a / 0; }
• Мертвый код
void test(int a){ if (a > 0) if (a < 0) a/0; }
Ошибки, специфичные для спецификаций (противоречия) (1)
59. Заголовок
• Verification Engineering of Safety
and Security Critical Industrial
Applications (VESSEDIA)
• STANCE project
• Programme Inter Carnot
Fraunhofer from BMBF and ANR
• Начало проекта - 2009
Пример ошибки в реальном проекте (1)
61. Заголовок
logic integer Count{L}(int *a, integer m, integer n, int v);
axiom CountSectionEmpty:
forall int *a, v, integer m, n;
n <= m ==> Count(a, m, n, v) == 0;
Пример ошибки в реальном проекте (2)
62. Заголовок
logic integer Count{L}(int *a, integer m, integer n, int v);
axiom CountSectionEmpty:
forall int *a, v, integer m, n;
n <= m ==> Count(a, m, n, v) == 0;
axiom CountSectionHit:
forall int *a, v, integer n, m;
a[n] == v ==> Count(a,m,n+1,v)==Count(a,m,n,v)+1;
Пример ошибки в реальном проекте (2)
63. Заголовок
logic integer Count{L}(int *a, integer m, integer n, int v);
axiom CountSectionEmpty:
forall int *a, v, integer m, n;
n <= m ==> Count(a, m, n, v) == 0;
axiom CountSectionHit:
forall int *a, v, integer n, m;
a[n] == v ==> Count(a,m,n+1,v)==Count(a,m,n,v)+1;
int a = 5;
assert Count(&a+1,0,-1,5) == 0 && Count(&a+1,0,0,5) == 0;
Пример ошибки в реальном проекте (2)
64. Заголовок
logic integer Count{L}(int *a, integer m, integer n, int v);
axiom CountSectionEmpty:
forall int *a, v, integer m, n;
n <= m ==> Count(a, m, n, v) == 0;
axiom CountSectionHit:
forall int *a, v, integer n, m;
a[n] == v ==> Count(a,m,n+1,v)==Count(a,m,n,v)+1;
int a = 5;
assert Count(&a+1,0,-1,5) == 0 && Count(&a+1,0,0,5) == 0;
assert Count(&a+1,0,0,5) == Count(&a + 1,0,-1,5)+1;
Пример ошибки в реальном проекте (2)
65. Заголовок
logic integer Count{L}(int *a, integer m, integer n, int v);
axiom CountSectionEmpty:
forall int *a, v, integer m, n;
n <= m ==> Count(a, m, n, v) == 0;
axiom CountSectionHit:
forall int *a, v, integer n, m;
a[n] == v ==> Count(a,m,n+1,v)==Count(a,m,n,v)+1;
int a = 5;
assert Count(&a+1,0,-1,5) == 0 && Count(&a+1,0,0,5) == 0;
assert Count(&a+1,0,0,5) == Count(&a + 1,0,-1,5)+1;
assert 0 == 1;
Пример ошибки в реальном проекте (2)
66. Заголовок
size_t strlen(const char *s) {
const char *sc;
for (sc = s; *sc != '0'; ++sc)
/* nothing */;
return sc - s;
}
Как выглядит разработка спецификации для функции? (1)
67. Заголовок
requires exists size_t i;
0 <= i && s[i] == '0' &&
valid(s+(0..i));
size_t strlen(const char *s)
Как выглядит разработка спецификации для функции? (2) (Контракт)
68. Заголовок
requires exists size_t i;
0 <= i && s[i] == '0' &&
valid(s+(0..i));
assigns nothing;
size_t strlen(const char *s)
Как выглядит разработка спецификации для функции? (2) (Контракт)
69. Заголовок
requires exists size_t i;
0 <= i && s[i] == '0' &&
valid(s+(0..i));
assigns nothing;
ensures s[result] == '0';
size_t strlen(const char *s)
Как выглядит разработка спецификации для функции? (2) (Контракт)
70. Заголовок
requires exists size_t i;
0 <= i && s[i] == '0' &&
valid(s+(0..i));
assigns nothing;
ensures s[result] == '0';
ensures forall size_t i; 0 <= i< result ==>
s[i] != '0';
size_t strlen(const char *s)
Как выглядит разработка спецификации для функции? (2) (Контракт)
71. Заголовок
const char *sc;
/*@ loop invariant s <= sc;
*/
for (sc = s; *sc != '0'; ++sc)
/* nothing */;
return sc - s;
Как выглядит разработка спецификации для функции? (3) (Инварианты цикла)
72. Заголовок
const char *sc;
/*@ loop invariant s <= sc;
loop invariant forall char *p;
s <= p < sc ==> *p != '0';
*/
for (sc = s; *sc != '0'; ++sc)
/* nothing */;
return sc - s;
Как выглядит разработка спецификации для функции? (3) (Инварианты цикла)
73. Заголовок
const char *sc;
/*@ loop invariant s <= sc;
loop invariant forall char *p;
s <= p < sc ==> *p != '0';
loop variant SIZE_MAX - (sc - s);
*/
for (sc = s; *sc != '0'; ++sc)
/* nothing */;
return sc - s;
Как выглядит разработка спецификации для функции? (3) (Инварианты цикла)
87. Заголовок
• Трудоёмкость
• В разы больше чем разработка
• Каждой строчке кода соответствует ~3-5 строчек
спецификаций
• Инструменты поддерживают не все конструкции языков
программирования
• Goto назад по коду
• Switch с “проваливающимися” case
• Цикломатическая сложность функций (< 15)
• …
• Применяется для проектов небольшого размера
• обычно не более 10 тыс. строк
Ограничения по применению дедуктивной верификации
88. Заголовок
• Серебряной пули не существует
• Формальная верификация имеет как плюсы, так и минусы
• Сложность применения
• Что мы доказываем (безопасность(safety), функциональные
требования)
• Предположения, исходя из которых проводится верификация
• Формальная верификация не гарантирует отсутствие всех ошибок
• Формальная верификация не является заменой тестированию
• При дедуктивной верификации существенна роль человека
Резюме
89. Заголовок
• Система верификации на основе Frama-
C+Jessie+Why3 опубликована под свободной
лицензией
• http://linuxtesting.ru/astraver
• Руководства и введение в инструменты на русском
• http://astraver.linuxtesting.org/
• Спецификации для библиотечных функций ядра Linux
• https://github.com/evdenis/verker/
Дополнительная информация