Верификация драйверов операционной системы Linux при помощи предикатных абстракций

Актуальность темы

.

В работе ставится задача верификации драйверов операционной системы (ОС) Linux. Обеспечение надежности и, в частности, информационной безопасности программных и программно-аппаратных систем является одной из главных задач современных информационных технологий. Особый вклад в решение этой задачи вносят работы по верификации системного программного обеспечения, в первую очередь операционных систем. Верификация драйверов ОС Linux является критически важной задачей, так как:

• Корректность драйверов является необходимым условием обеспечения надежности и безопасности систем, поскольку драйверы работают с тем же уровнем привилегий, что и остальное ядро.

• Драйверы ОС Linux, входящие в ядро, это большой, стремительно растущий класс программных систем. На данный момент суммарный объем драйверов составляет более 9 миллионов строк исходного кода. За последний год он увеличился на полмиллиона строк.

Для драйверов, которые входят в состав ядра, обеспечение качества проводится силами разработчиков ядра. По данным Linux Foundation, на сегодняшний день в разработке каждой версии ядра, выходящей раз в 2−3 месяца, участвуют более 1000 человек, представляющих более 200 различных организаций. Несмотря на такое большое количество разработчиков, значительное число изменений в уже выпущенных и новых версиях ядра связано с исправлением ошибок в драйверах. Так, например, анализ изменений в драйверах стабильных версий ядра за год разработки с 26.10.10 по 26.10.11 показал, что порядка 80% изменений являются исправлениями ошибок. Происходит это в силу того, что обеспечивать надежность драйверов ОС Linux затруднительно ввиду огромного количества достаточно сложного исходного кода, который должен удовлетворять большому числу разнообразных правил корректности, начиная от общих правил, которым должны подчиняться все программы на Си, и заканчивая специфичными правилами, которые говорят о том, как драйверы должны использовать интерфейс ядра.

Методы общецелевого статического анализа позволяют обнаруживать нарушения общих правил, таких как разыменование нулевых указателей, выход за границу массива. Однако, помимо них остается значительная часть специфичных для ОС Linux ошибок взаимодействия драйвера с интерфейсом ядра. По данным анализа изменений в драйверах стабильных версий ядра за год разработки с 26.10.10 по 26.10.11 количество специфичных ошибок составляет более половины от всех ошибок, являющихся нарушениями правил корректности.

Перспективным направлением является разработка высокоточных инструментов статической верификации при помощи предикатных абстракций. Примерами являются инструменты BLAST, CPAchecker, SLAM. За счет построения предикатных абстракций они позволяют показать не только наличие ошибок, но и их отсутствие для заданного правила.

Ключевым свойством высокоточных инструментов для проверки специфических правил является возможность итеративного уточнения абстракции по методу CEGAR (Counter Example Guided Abstraction-Refinement), что позволяет подстраивать абстракцию как под произвольное правило корректности, так и для конкретного драйвера. Это выгодно отличает такие инструменты от общецелевых, в которых настройка под правило корректности требует реализации соответствующей функциональности в инструменте статического анализа.

Применение инструментов высокоточного статического анализа к драйверам ОС Linux имеет хорошие предпосылки. Высокоточные методы в настоящее время имеют ограничения по размеру анализируемого кода (до 50−100 тыс. строк). В случае драйверов это ограничение приемлемо. Размер драйверов, входящих в состав ядра ОС Linux, не превышает 50 тысяч строк, а в среднем составляет порядка 2−3 тыс. строк кода. Кроме того, важно, что большинство драйверов публикуется вместе с исходным кодом, который является необходимым для большинства инструментов статического анализа.

Для применения высокоточных инструментов требуется подготовка драйвера к верификации. Во-первых, требуется подготовить специальное окружение драйвера, которое должно описывать возможности воздействия на него с учетом ограничений, накладываемых на взаимодействия сердцевины ядра ОС с драйверами данного типа. Во-вторых, требуется формально описать правила корректности в виде, удобном для сведения задачи верификации к доказательству достижимости точки программе. При решении этих задач необходимо учитывать специфику ядра ОС Linux. Одна из главных особенностей состоит в том, что интерфейсы между драйвером и ядром ОС Linux постоянно меняются. Меняются правила взаимодействия, появляются новые, меняется окружение драйвера. Поэтому правила, модели окружения и другие части системы верификации должны быть устроены так, чтобы обеспечивать простоту развития, адаптации к текущему состоянию ядра ОС, правилам взаимодействия между драйверами и ОС. На сегодняшний день не существует методов верификации, учитывающих данные особенности.

Таким образом, задача верификации драйверов ОС Linux является актуальной, для ее решения требуется разработка нового метода верификации.

Цель и задачи работы.

Цель работы — разработка метода верификации драйверов устройств операционных систем для проверки выполнения правил корректного взаимодействия драйверов с ядром операционной системы.

Для достижения цели работы были поставлены следующие задачи:

1. Провести анализ существующих методов верификации драйверов;

2. Провести анализ ошибок в драйверах ОС Linux, приводящих к некорректному взаимодействую с ядром ОС;

3. Разработать метод верификации и архитектуру системы верификации драйверов ОС Linux при помощи предикатных абстракций, обеспечивающий:

• верификацию драйверов в условиях непрерывного развития ядра;

• возможности расширения (конфигурируемости) системы верификации драйверов за счет пополнения набора правил корректности и набора инструментов верификации.

4. Разработать систему верификации, реализующую метод;

5. Оценить реализацию метода на практике, дать оценку области применимости метода.

Научная новизна работы.

Научной новизной обладают следующие результаты работы:

1. Метод построения моделей окружения драйверов устройств ОС Linux;

2. Метод построения конфигурируемой системы верификации;

3. Математическое доказательство адекватности предложенного метода формализации правил корректности в рамках заданного класса правил работы со структурами обработчиков событий;

4. Методы оптимизации предикатной абстракции в BLAST.

Практическая значимость.

На основе разработанного метода была создана система верификации драйверов ОС Linux LDV (Linux Driver Verification). Система LDV позволяет находить нарушения правил корректности взаимодействия с ядром ОС для драйверов, входящих в поставку ядер ОС Linux с версии 2.6.31 по 3.4. По состоянию на 25.09.2012 было найдено более 60 ошибок, которые признаны разработчиками ядра и уже исправлены или будут исправлены в последующих версиях.

Результаты работы будут полезны для автоматизации сертификационных процессов для компьютерного обеспечения, которые существуют у многих поставщиков дистрибутивов ОС Linux и ОС, построенных на основе ядра Linux. Также результаты могут быть использованы для проверки качества драйверов ОС Linux, для создания инструментов верификации других видов программного обеспечения, критичного по безопасности. Результаты работы могут быть использованы для сравнения характеристик различных инструментов статического анализа кода.

Доклады и публикации.

По теме диссертации автором опубликовано 15 работ [1−15] (из них 5 в изданиях из перечня ВАК [1−5]).

Основные положения работы докладывались на следующих конференциях и семинарах:

• Весенний коллоквиум молодых исследователей в области программной инженерии (SYRCoSE: Spring Young Researchers Colloquium on Software Engineering, г. Санкт-Петербург, 2008 г.);

• Общероссийская научно-техническая конференция «Методы и технические средства обеспечения безопасности информации» (г. Санкт-Петербург, 2008 г.);

• Международный семинар «Принципы и технические средства сертификации свободного программного обеспечения» (OpenCert: International Workshop on Foundations and Techniques for Open Source Software Certification, г. Милан, 2008 г.);

• Конференция разработчиков свободных программ на Протве (г. Обнинск, 2009 г.);

• Международная конференция памяти академика А. П. Ершова «Перспективы систем информатики» (PSI: Perspectives of System informatics, г. Новосибирск, 2011 г.);

• Международная конференция по инструментам и алгоритмам создания и анализа систем (TACAS: International Conference on Tools and Algorithms for the Construction and Analysis of Systems, г. Таллин, 2012 г.);

• Семинар «День свободного программного и аппаратного обеспечения» (г. Москва, 2012 г.);

• Семинар Института системного программирования РАН (г. Москва, 2012 г.).

Структура и объем диссертации

.

Работа состоит из введения, семи глав, заключения и списка литературы (55 наименований). Основной текст диссертации (без приложений и списка литературы) занимает 115 страниц.

4.4. Выводы.

В данной главе были рассмотрены следующие методы оптимизации, реализованные в инструменте BLAST 2.7:

• Настройка автоматического управления памятью в языке OCaml позволила уменьшить время, затрачиваемое на операции с памятью, что дало 20% прироста в количестве посещенных точек проверяемой программы на затраченную единицу памяти.

• В синтаксическом анализаторе CIL, используемым инструментом BLAST, были внесены исправления, которые позволили успешно анализировать до 98% драйверов ядра (измерено на версии 2.6.37), и лишь около 2% приводят к ошибкам разбора. До этого BLAST 2.5 не мог разобрать ни одного драйвера в ядре 2.6.31.

• Была улучшена работа с решателями, получающими на вход формулы в формате SMTLIB, за счет снижения накладных расходов при конвертации формул из внутреннего представления.

• Оптимизирован алгоритм фильтрации формулы пути, который осуществляет удаление частей формулы, не влияющих на получение ин-терполянта. Время работы алгоритма стало 0(log N), вместо O (N).

• Был реализован новый алгоритм анализа алиасов, который позволяет анализировать программы, использующие указатели на базовые типы и структуры.

Данные улучшения позволили инструменту BLAST 2.7 занять первое место в категории DeviceDrivers64 и третье в категории DeviceDrivers32 на международных соревнованиях по верификации программ SV-COMP 2012 [68].

Глава 5.

Система верификации драйверов ОС Linux.

Система верификации LDV (Linux Driver Verification) является реализацией метода верификации, описанного в главе 2.

Разработанная система верификации обладает следующими важными особенностями:

• Система интегрирована с процессом сборки ядра, поэтому вся необходимая информация о составе и настройках сборки драйверов извлекается автоматически.

• Генерация окружения осуществляется полностью автоматически на основе иерархии шаблонов, покрывающей все типы драйверов.

• Система позволяет добавлять новые правила корректности с помощью аспектно-ориентированного расширения языка программирования Си.

• Система поддерживает встраивание внешних инструментов статической верификации с помощью написания адаптеров.

• Для анализа трасс ошибок и сравнительного анализа результатов система предоставляет специальные компоненты с Веб-интерфейсом.

5.1. Пользовательский интерфейс системы.

Пользователь взаимодействует с системой верификации LDV посредством высокоуровневого интерфейса командной строки LDV manager. Данный компонент позволяет проверить некоторый набор драйверов (внутренних или внешних) для некоторого набора ядер по одному или нескольким правилам корректности. В том случае, когда в ходе работы не происходит критическая исключительная ситуация, на выходе LDV manager создает архив, содержащий результаты анализа, информацию о работе компонентов архитектуры LDV, трассы ошибок и необходимые для их визуализации файлы с исходным кодом драйверов и ядра ОС Linux. Далее данный архив может быть загружен в базу данных и использован для анализа, например, с помощью Statistics Server.

Statistics Server — это компонент, который предоставляет веб-интерфейс для статистического анализа и сравнения результатов верификации.

Statistics Server позволяет анализировать большие объемы данных, получаемых в ходе верификации драйверов различных версий ядра ОС Linux по множеству правил с помощью инструментов статической верификации, запускаемых с разными конфигурациями. Помимо статистки, такой как, например, суммарное количество различных вердиктов для некоторого ядра и правила, компонент позволяет анализировать детальные списки, например, посмотреть все драйверы некоторого ядра, для которых инструмент верификации выдал вердикт Unsafe на некотором правиле корректности.

Система верификации LD V изначально проектировалась для использования различной целевой аудиторией такой, как разработчики компонентов, разработчики ядра, разработчики инструментов верификации достижимости и т. д. Как правило, запросы к представлению статистики у этих групп отличаются, поэтому Statistics Server предлагает различные заранее подготовленные профили представления данных. Так, например, разработчикам инструментов верификации достижимости помимо статистики по вердиктам предоставляется статистика по времени, затраченном на верификациюразработчикам компонентов показывается статистика по внутренним проблемам соответствующих компонентов.

Еще одна важная возможность компонента — это возможность сравнения результатов различных заданий верификации. В частности, это оказывается очень полезным и удобным инструментом для сравнения различных инструментов статической верификации, в том числе, различных версий и конфигураций.

Statistics Server интегрирован с Error Trace Visualizer, компонентом, который нацелен на упрощение анализа трасс ошибок, которые выдают инструменты верификации достижимости в случае вынесения вердикта Unsafe. Данный компонент позволяет ускорить анализ трасс ошибок, благодаря чему существенно повышается степень автоматизации процесса верификации в целом. Error Trace Visualizer подробно описан в статье [69].

Как правило, трасса ошибки представляется в текстовом виде, который имеет весьма специфичный, вообще говоря, сильно зависящий от инструмента верификации, формат. Для некоторых инструментов статической верификации существуют инструменты, позволяющие представить трассы ошибок в более наглядном и удобном для анализа формате. Например, трассу ошибки инструмента статической верификации CPAchecker можно преобразовать в HTML, после чего ее можно открывать в любом браузере. Трассы ошибок SATABS визуализируются посредством специального Eclipse плагина. А, например, инструмент статической верификации BLAST до Error Trace Visualizer не имел инструментов, позволяющих упростить анализ трасс ошибок. Подобное многообразие форматов представления трасс ошибок, в конечном итоге, затрудняет их анализ для различных инструментов верификации.

В рамках проекта LDV был разработан общий формат представления трасс ошибок. Разработанный формат является в достаточной степени гибким и расширяемым, что позволяет преобразовывать к нему трассы ошибок различных инструментах верификации без больших трудозатрат. Преобразование исходных трасс ошибок к общему формату реализуется на уровне адаптеров инструментов верификации. Для инструментов BLAST и CPAchecker подобное преобразование было реализовано разработчиками LDV. Error Trace Visualizer визуализирует трассы, представленные в общем формате, единообразным образом и показывает результаты с помощью веб-интерфейса.

Важно отметить, что при визуализации наряду с трассой ошибок Error Trace Visualizer показывает соответствующий ей исходный код программы, причем, между ними устанавливаются определенные взаимосвязи (например, соответствие строк трассы ошибки строкам исходного кода программы). Также компонент выделяет каждый класс элементов трассы ошибки определенным стилем и цветом. Для показываемого исходного кода программы выполняется синтаксическая подсветка. Имеется возможность скрывать и раскрывать как отдельные элементы, так и целые классы элементов трассы ошибки. Все это существенно облегчает анализ трасс ошибок различных инструментов верификации.

5.2. Разработка адаптера инструмента верификации.

Для использования инструмента статической верификации необходим адаптер, в котором можно выделить следующие четыре части:

• подготовка входных файлов;

• подготовка обработчика вывода инструмента верификации;

• запуск инструмента;

• обработка результатов.

Далее рассмотрены данные части по отдельности с указанием того, какие средства предоставляются разработчику адаптера для реализации соответствующих задач.

В рамках одной задачи инструменту верификации необходимо проверить достижимость ошибочной метки из некоторой точки входа, причем анализируемая программа может быть расположена в одном или нескольких файлах. Инструменты верификации могут накладывать ограничения на то, в каком виде должны быть представлены эти файлы. Разработчику адаптера предоставляется возможность применить к каждому из входных файлов стандартный препроцессор языка Си, обработать файлы с помощью инструмента трансформации кода CIL, или соединить все файлы в один с помощью того же CIL [70]. В результате возвращается список файлов, в которых содержится весь необходимый для проверки исходный код.

Обработчику вывода инструмента верификации на вход подаются строчки, выдаваемые инструментом верификации на стандартный вывод и/или на стандартный поток ошибок. Обработчик опционально возвращает набор значений с некоторой информацией, которую он извлек из трассы (например, последние 20 строк или вердикт о наличии/отсутствии в программе ошибок). Каждая функция-обработчик хранит свое внутреннее состояние. Непосредственно перед запуском инструмента верификации адаптер регистрирует такие функции, a Reachibihty С Verifier применяет их, когда инструмент верификации будет запущен, параллельно с его работой.

Запуск инструмента верификации заключается в вызове библиотечной функции с командной строкой, соответствующей вызову инструмента верификации. Подготовка аргументов осуществляется в индивидуальной для каждого инструмента манере, на основе полученных имен препроцессированных файлов, точки входа и ошибочной метки. Библиотечная функция, через которую адаптер осуществляет вызов инструмента, отличается от стандартной функции вызова внешней программы некоторыми функциональными особенностями, а именно:

• автоматически применяет функции обработчики вывода, зарегистрированные адаптером ранее;

• вывод инструмента, который может быть большим по объему, архивируется и сохраняется на диск;

• инструмент запускается в контролируемом окружении, позволяя лимитировать использование инструментом и его дочерними процессами ресурсов машины, а именно потребления памяти, дискового пространства и процессорного времени;

• по желанию разработчика адаптера, происходит измерение потребления запускаемым инструментом и всеми его дочерними процессами временипри этом разработчик адаптера может указать, измерение времени в каких именно процессах ему интересно и в какие категории каждый из них следует отнести.

После окончания запуска адаптер получает информацию о причине окончания (нарушение лимита ресурсов, получение сигнала или успешное завершение), коде возврата и номеру завершившего процесс сигнала, а также информацию, собранную функциями обработчиками вывода трассы. Ожидается, что в адаптере разработчик реализует автоматизированную интерпретацию этой информации. Например, разработчик адаптера должен реализовать интерпретацию трассы ошибки соответствующего инструмента статической верификации и ее преобразование в специальный общий формат, используемый для визуализации этой трассы.

Адаптер также может передать произвольную текстовую строку (например, содержащую исключение и трассу стека, выброшенные инструментом при неудачном завершении) и один или несколько файлов для сохранения их в финальном отчете с результатами верификации. Затем эта информация может быть использована для последующей обработки и построения статистики с помощью компонента LDV Statistics Server.

Разработчик адаптера также может добавить конфигурируемость адаптеров, чтобы проводить эксперименты с различными настройками инструментов верификации без необходимости модифицировать код адаптера каждый раз. Например, для конфигурации разработчик адаптера может использовать переменные окружения.

Глава 6.

Методика выявления и классификации правил корректности.

6.1. Выбор источника.

Для выявления правил корректности достаточно много информации можно найти в документации, в том числе, входящей в состав ядра и в исходный код ядра и драйверов, а также в литературе по разработке драйверов и ядра ОС Linux.

Однако, в этих источниках документированы далеко не все особенности различных подсистем ядра и типов драйверов. Поскольку ядро развивается очень стремительно, данные источники не всегда поддерживаются в актуальном состоянии.

В качестве еще одного источника для выявления правил можно рассмотреть список рассылки ядра Linux (от англ. Linux Kernel Mailing List, LKML). В данном списке рассылки обсуждаются различные актуальные вопросы разработки ядра, в том числе вопросы, связанные с исправлением ошибок. На основании этих обсуждений можно выявить множество общих и специфичных правил, но анализ сообщений в LKML достаточно трудоемок, поскольку сообщений много и они содержат большое количество информации, причем не только технической. Кроме того, много ошибок обсуждается в других списках рассылок, на форумах, системах отслеживания ошибок и т. д.

Правила корректности можно выявлять на основе анализа журнала изменений, содержащего изменения, вносимые в драйверы ОС Linux. Данный источник является достаточно актуальным, поскольку рано или поздно среди изменений появляются все важные исправления ошибок, которые обсуждаются в различных списках рассылок, на конференциях, форумах и т. д. Изменения в драйверах ОС Linux проходят достаточно тщательную предварительную процедуру согласования и проверки, в том числе, у экспертов в соответствующих подсистемах ядра.

Каждое изменение содержит в себе достаточно подробную информацию, включающую сведения об авторе, краткое название изменения, подробное описание (возможно, со ссылками на соответствующие обсуждения), изменение исходного кода драйверов и/или ядра ОС Linux и различную вспомогательную информацию.

В качестве основного источника для выявления правил будем использовать журнал изменений.

6.2. Методика анализа журнала изменений.

Первый шаг методики анализа изменения в драйвере ОС Linux заключается в том, чтобы определить, является ли оно исправлением ошибки или оно каким-либо образом расширяет функциональность драйвера (например, добавляет поддержку новых устройств).

Далее из рассмотрения исключаются ошибки, исправления которых связано с требованиями к функциональности конкретного драйвера или ошибки взаимодействия драйвера с конкретным оборудованием. Это так называемые «нетиповые» ошибки. В том случае, если ошибка связана с неправильным использованием специализированных для конкретного драйвера или группы драйверов констант, условий и вычислений, ее следует исключить из дальнейшего рассмотрения, так как для нее нельзя сформулировать правило корректности.

Основным шагом предлагаемой методики анализа изменений в драйверах ОС Linux является классификация ошибок, для которых можно сформулировать правила.

Среди типовых ошибок можно выделить три класса. В первый класс входят общие ошибки в драйверах, как в программах на языке программирования Си (ядро и драйверы ОС Linux разрабатываются на языке программирования Си). Например, разыменовывание нулевого указателя, превышение максимально возможных значений переменных с целым типом и т. п. Ко второму классу относятся специфичные ошибки, связанные с неправильным использованием интерфейса сердцевины ядра. К числу таких ошибок относятся, например, нарушения правил инициализации переменных, имеющих специфичные типы. Третий класс типовых ошибок включает в себя состояния гонок и взаимные блокировки, которые возникают при параллельном выполнении вследствие неиспользования или неправильного использования механизмов синхронизации.

Данный шаг требует осмысления причины, которая привела к ошибке. Дело в том, что с первого взгляда может показаться, что ошибка проявилась вследствие нарушения некого общего правила. На самом деле, причина ошибки может крыться в особенностях параллельного выполнения либо в некорректном использовании интерфейса сердцевины ядра. Кроме того, не всегда легко определить, какую именно общую или специфичную ошибку исправляет рассматриваемое изменение. На данном шаге помимо анализа описания и изменения в исходном коде предполагается более тщательный анализ взаимодействий различных подсистем ядра и драйвера.

Важно отметить, что список классов неизвестен заранее и может быть определен только непосредственно по ходу самого анализа. Предполагается, что, в первую очередь, классы позволят различить общие и специфичные ошибки в драйверах. commit 5fc8fe8e2ea30805bee5al3420817d6ad34ea9ce Author Anders Larsen Date Wed Oct 6 23 46 25 2010 +0200.

USB cp210x Add WAGO 750−923 Service Cable device ID commit 93ad03d60b5bl8897030038234aa2ebae8234748 upstream.

The WAGO 750−923 USB Service Cable is used for configuration and firmware updates of several industrial automation products from WAGO Kontakttechnik GmbH skipped).

Signed-off-by Anders Larsen Signed-off-by Greg Kroah-Hartman diffgit a/drivers/usb/serial/cp210x с b/drivers/usb/serial/cp210x с index 3ad53bd 9927bca 100 644 a/drivers/usb/serial/cp210x с + + + b/drivers/usb/serial/cp210x с -132 6 +132 7 @@ static const struct usbdeviceid idtable[] = { USBDEVICE (0xl7F4, OxAAAA) >, /* WavesenseJazz blood glucose meter*/ { USBDEVICE (0×1843, 0×0200) > /* Vaisala USB Instrument Cable */ { USBDEVICE (0xl8EF, OxEOOF) >, /* ELV USB-l2C-lnterface */ + { USBDEVICE (0xlBE3, 0×07A6) }, /* WAGO 750 923 USB Service Cable */ { USBDEVICE (0×413C, 0×9500) }, /* DW700 GPS USB interface */ { } I* Terminating Entry */.

Рис 6 1 Описание изменения 5fc8fe8, добавляющего поддержку нового устройства.

6.2.1. Примеры применения предложенной методики.

Рассмотрим применение предложенной методики на примерах На основании описания и изменения в исходном коде для изменения в драйвере, представленного на Рис 6.1 можно сделать вывод, что данное изменение в драйвере не является исправлением ошибки, а добавляет поддержку нового USB устройства.

Изменение в драйвере на Рис 6.2 демонстрирует исправление нетиповой ошибки, вызванной нарушением контракта драйвера трекпада Изменение исходного кода задействует специфичные для данного драйвера константы и ограничения.

На Рис 6 3 представлено изменение в драйвере, которое является исправлением типовой специфичной ошибки. Данная ошибка вызвана неправильным использованием интерфейса сердцевины ядра, а именно, в контексте блокировки вызывается функция выделения памяти, которая может перевеcommit 8e6b41c76c5b8a27b2abd7b9f6ed0877987fdllb Author Chase Douglas Date Tuejan 11 19 37 50 2011 +0100.

HID magicmouse Don’t report REL{X, Y} for Magic Trackpad Linus' tree commit 6a66bbd693cl2f71697c61207aal8bc5al2da0ab ].

With the recent switch to having the hid layer handle standard axis initialization, the Magic Trackpad now reports relative axes This would be fine in the normal mode, but the driver puts the device in multitouch mode where no relative events are generated Also, userspace software depends on accurate axis information for device type detection Thus, ignoring the relative axes from the Magic Trackpad is best.

Signed-off-by Chase Douglas cchase douglas@canonical com> Signed-off-by Jiri Kosina Signed-off-by Greg Kroah-Hartman diff —git a/drivers/hid/hid-magicmouse с b/drivers/hid/hid-magicmouse с index e6dcl51 ed732b7 100 644 — a/drivers/hid/hid-magicmouse с + + + b/drivers/hid/hid-magicmouse с -433,6 +433,11 @@ static int magicmouseinputmapping (struct hiddevice *hdev, if ('msc->input) msc->input = hi->input, Л Magic Trackpad does not give relative data after switching to MT */ + if (hi->input >id product == USBDEVICEIDAPPLEMAGICTRACKPAD && + field->flags & HIDMAINITEMRELATIVE) return -1 return 0,.

Рис 6 2 Описание изменения 8е6Ь41с, исправляющего петиповую ошибку commit 83a9a8034ee98ac21804c376ec90af8e4997790e Author John Johansen Date Wed Jun 8 15 07 47 2011 -0700.

AppArmor Fix sleep in invalid context from tasksetrlimit commit 1780f2d3839a0d3eb85ee014a708f9e2c8f8ba0e upstream Affected kernels 2 б 36 — 3 0.

AppArmor may do a GFPKERNEL memory allocation with tasklock (tsk->groupleader), held when called from securitytasksetrlimit This will only occur when the task’s current policy has been replaced, and the task’s creds have not been updated before entering the LSM securitytasksetrlimit () hook.

BUG sleeping function called from invalid context at mm/slub с 847 inatomic () 1, irqsdisabled () 0, pid 1583, name cupsd skipped).

Signed-off-by John Johansen Reported-by Miles Lane Signed-off-by James Morris Signed-off-by Greg Kroah-Hartman diff —git a/security/apparmor/lsm с b/security/apparmor/lsm с index eclbcec 3d2fdl4 100 644 — a/security/apparmor/lsm с + + + b/secunty/apparmor/lsm с -612,7 +612,7 @@ static int apparmorsetprocattr (struct taskstruct *task char 'name static int apparmortasksetrlimit (struct taskstruct *task, unsigned int resource, struct rlimit *newrlim) struct aaprofile +profile = aacurrentprofile () struct aaprofile^profile =aacurrentprofile () int error = 0, if ('unconfined (profile)).

Рис 6 3 Оппсаиие изменения 83a9a80, исправляющего типовую специфичную ошибку (вызов функции, которая может заснуть, в контексте блокировки) сти процесс в режим ожидания.

6.3. Классификация ошибок взаимодействия драйверов с ядром ОС Linux.

Подробное описание анализа можно найти в статье [1].

В рамках основного анализа рассматривались изменения, которые были сделаны в стабильных ядрах с 2.6.35 по 3.0 в репозитории [71] за время, начиная с 26 октября 2010 года по 26 октября 2011 года. Всего таких изменений насчитывается 3101. Среди данных изменений некоторые являются дубликатами, поскольку одни и те же изменения попадают в различные стабильные ветки. Уникальных изменений за указанный период времени насчитывается 2623 (около 84.6% от общего числа изменений). Для того чтобы отделить изменения в драйверах от остальных изменений в ядре, рассматривались только такие изменения, которые затрагивали файлы из папок: crypto, drivers, sound, security, include/acpi, include/crypto, include/drm, include/media, include/mtd, include/pcmcia, include/rdma, include/rxrpc, include/scsi, include/sound и include/video. Из всех уникальных изменений, сделанных в стабильных ядрах с 26.10.10 по 26.10.11, в драйверах оказалось 1503, т. е. около 57.3% от общего числа уникальных изменений. Сводные результаты основного анализа изменений в драйверах представлены в Табл. 6.1. Подробное описание анализа можно найти в статье [1].

В соответствии с методикой, предложенной в данной работе, была произведена классификация выявленных типовых ошибок. При классификации не рассматривались изменения, которые являются исправлением типовых специфичных ошибок, связанных с некорректным использованием интерфейса группы драйверов (47 изменений). Изменениям, которые включали исправления сразу нескольких ошибок, приписывалось соответствующее количество.

Изменения в драйверах (1503).

Расширение функциональности (321 — 21%) Исправление ошибок (1182 — 79%).

Нетиповые ошибки (786 — 67%) Типовые ошибки (396 — 33%).

Заключение

.

Основные научные и практические результаты, полученные в диссертационной работе и выносимые на защиту, состоят в следующем:

1. Разработан метод верификации драйверов устройств операционных систем для проверки выполнения правил корректного взаимодействия драйверов с ядром операционной системы;

2. Разработан метод построения моделей окружения драйверов устройств ОС Linux;

3. Разработан метод построения конфигурируемой системы верификации, обеспечивающий возможность расширения системы за счет пополнения набора правил корректности и набора инструментов верификации;

4. Разработаны методы оптимизации предикатной абстракции в инструменте BLAST;

5. На основе предложенных методов разработана система верификации драйверов ОС Linux.

Система верификации драйверов ОС Linux разработана в рамках проектов отдела Технологий программирования Института системного программирования РАН при непосредственном участии автора в качестве руководителя и участника разработки основных компонентов системы верификации. Автор выражает свою признательность всем участникам данных проектов. Особый вклад в работу внесли А. В. Хорошилов, Е. М. Новиков, П. Е. Швед.