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

Мандрыкин М.У.; Хорошилов А.В.

Труды ИСП РАН, том 27, вып. 4, 2015 г..

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

1М.У. Мандрыкин <[email protected]>

1,2, з, р Хорошилов <[email protected]>

1ИСП РАН, 109004, Россия, г. Москва, ул. А. Солженицына, дом 25 2119991 ГСП-1 Москва, Ленинские горы, МГУ имени М.В. Ломоносова, 2-й учебный корпус, факультет ВМК

3Московский физико-технический институт (государственный университет), 141700, Московская область, г. Долгопрудный, Институтский пер., 9 4НИУ ВШЭ, Россия, Москва, 101000, ул. Мясницкая, д. 20

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

Ключевые слова: Верификация, параллелизм, владение, инварианты, семантика языка С.

1. Введение

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

1 Исследование проводилось при финансовой поддержке Министерства образования и науки Российской Федерации (уникальный идентификатор проекта -RFMEFI60414X0051).

49

Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 4, 2015.

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

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

50

Труды ИСП РАН, том 27, вып. 4, 2015 г..

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

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

Целью проекта Astraver [1] является развитие набора инструментов для высокоавтоматизированной дедуктивной верификации модулей ядра Linux. Набор инструментов разрабатывается на основе двух платформ анализа исходного кода и дедуктивной верификации. Первая, внешняя платформа - Frama-C [2] -это пакет инструментов для анализа исходного кода ПО, написанного на языке С. Frama-c - расширяемая и модульная платформа с архитектурой на основе динамически подключаемых модулей, которая включает свой собственный подключаемый модуль дедуктивной верификации WP [3], а также позволяет создавать и использовать сторонние подключаемые модули. В частности, модуль Jessie [4], который изначально был частью платформы дедуктивной верификации Why, был отщеплен и в настоящее время разрабатывается в рамках проекта Astraver. Являясь полноценным практическим средством анализа исходного кода на языке С, платформа Frama-C обеспечивает хорошую совместимость с диалектом GNU С, включая его различные специфичные возможности и расширения, используемые в коде ядра Linux. Frama-C также предоставляет свою собственную адаптированную модификацию инфраструктуры CIL [5] для анализа и трансформации исходного кода, которая значительно облегчает реализацию серии преобразований и нормализации исходного кода, применяемых модулем Jessie с целью предварительного упрощения сложной модели памяти и семантики исходной С-программы. Модуль Jessie реализует дедуктивную верификацию путем перевода исходной программы на языке С вместе с соответствующими функциональными спецификациями, написанными на специальном языке спецификаций ACSL [6], в набор модулей на языке программирования и спецификации Why3ML [7], являющемся входным языком платформы дедуктивной верификации Why3 [8]. Таким образом, платформа Why3 служит второй, внутренней платформой дедуктивной верификации, предоставляющей выразительный входной язык и реализующей управление УВ: их генерацию, преобразование, разрешение с использованием внеш-

51

Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 4, 2015.

них инструментов проверки выполнимости и управление ручными доказа-тельствами. Why3 реализует расширяемый механизм поддержки внешних инструментов проверки выполнимости (решателей и доказателей теорем), с использованием которого в инструменте реализована встроенная поддержка нескольких решателей формул в теориях ([9], [10]), доказателей теорем на основе расширения резолютивного вывода ([11], [12]) и интерактивных доказателей теорем ([13], [14]). Эффективность кодирования УВ достигается модулями WP и Jessie по-разному. В то время как модуль WP обеспечивает гибкость и эффективность, реализую генерацию УВ напрямую, реализуя высокоуровневые преобразования УВ (с помощью модуля Qed [3]) и несколько различных моделей памяти (“модель Хоара”, типизированную и побитовую модели), которые могут быть заданны отдельно для каждого УВ, модуль Jessie реализует одну оптимизированную гибридную модель памяти на основе регионов [15] и эффектов [16] с частичной поддержкой явной низкоуровневой переинтерпретации типов указателей [17], оставляя непосредственно генерацию и управление (в том числе различные преобразования) УВ платформе Why3. В ходе начальной стадии исследований в рамках проекта Astraver, модель памяти Jessie (со значительными модификациями [17]) показала достаточную выразительность для представления последовательной части семантики фрагментов кода ядра Linux (включая различные виды приведений типа указателей и побитовые операции). В то же время в к настоящему времени ни в платформе Frama-C, на в платформе Why3 не была реализована поддержка параллельной части семантики для какого-либо класса параллельных программ на языке С. Как и большая часть современного системного программного обеспечения, модули ядра Linux работают параллельно. Более того, в коде ядра Linux широко используются неблокирующие механизмы синхронизации, такие как атомарные операции, барьеры и особенно RCU [18].

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

52

Труды ИСП РАН, том 27, вып. 4, 2015 г..

кающем пространстве чередований с помощью переноса инвариантов, ранее сопоставленных точкам в потоке управления последовательной программы, на типы данных, с которыми работает параллельная программа. С учетом такого изменения методологии (при определенных дополнительных ограничениях на инварианты используемых типов данных) введение дисциплины синхронизации позволяет свести полный перебор всевозможных чередований к так называемому крупнозернистому параллелизму, в рамках которого вмешательство параллельных потоков выполнения может происходить только в относительно небольшом числе явно обозначенных точек в потоке управления программы, а заданные инварианты типов данных требуется проверять лишь локально, то есть на заранее известном конечном множестве отрезков путей выполнения. Это позволяет полностью восстановить локальность метода верификации ценой потери гарантии завершимости параллельной программы. Методология владения с локально проверяемыми двухметочными инвариантами (англ, locally-checked two-state invariants, сокр. LCI) [22] является одним из таких локальных методов верификации параллельных программ. Основные понятия, водимые в методологии владения, - двухметочный инвариант, взаимная допустимость инвариантов и динамическое утверждение. Вместе они составляют основу локального метода дедуктивной верификации параллельных программ с использованием инвариантов типов данных. Общая методология владения может быть приспособлена для рассуждений в классической логике первого порядка, поддерживаемой большинством современных автоматических средств логического вывода, и ранее была успешно применена в инструменте дедуктивной верификации VCC [20].

В то время как многие локальные методы верификации многопоточных программ допускают использование только блокирующих примитивов синхронизации [19], инструмент VCC реализует модель параллелизма, позволяющую выражать многие варианты использования как блокирующих, так и неблокирующих примитивов. Модель параллелизма VCC является расширением общей методологии LCI дополнительными операциями атомарных обновлений асинхронно-изменяемых (англ, volatile) данных. По многим характеристикам инструмент VCC является концептуально схожим с набором Frama-c - Jessie -Why3, в частности, он использует в качестве входного языка подмножество языка С, расширенное собственным языком спецификаций, предполагает использование некоторой модели типизированных объектов поверх языка С, реализует типизированную модель памяти с явной переинтерпретацией [21], а также использует решатель формул Z3 [9] (поддерживаемый Why3) в качестве средства автоматического логического вывода.

В данной статье предлагается предварительное описание расширения языка спецификаций ACSL, поддерживаемого платформой анализа С-программ Frama-C, набором примитивов методологии LCI, аналогичных тем, которые включены в язык спецификаций для инструмента VCC, а также приводится несколько примеров использования предлагаемых расширений для формализации примитивов синхронизации, включая модель для проверки корректно-

53

Trudy ISP RAN [The Proceedings of ISPRAS], vol. 27, issue 4, 2015.

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

2. Методология владения и LCI

Методология владения - это объектно-ориентированная дисциплина синхронизации, предполагающая, что каждый поток управления может осуществлять последовательные (неатомарные) операции записи только в объекты, которыми этот поток владеет и может осуществлять любые операции чтения только из объектов, которыми он либо владеет, либо имеет возможность доказать, что во время чтения эти объекты не будут изменены (иначе говоря, останутся закрытыми). Объекты как вершины, связанные направленными дугами, соответствующими отношению владения, организуются в лес, в котором каждый объект всегда имеет строго одного владельца, отличного от самого объекта, кроме потоков управления, которые также рассматриваются как объекты, всегда владеющие самими собой. Объектам типизированы и каждому типу объектов приписывается некоторый набор двухметочных инвариантов, которые ограничивают возможные операции обновления объектов соответствующего типа и могут быть сформулированы с использованием значений из состояния объекта как до, так и после его обновления. Несколько идущих подряд обновлений одного объекта могут быть объединены в серию так, что каждая такая серия обновлений (операция последовательной записи) может быть представлена для системы в целом как одно атомарное обновление состояния объекта. Это соответствует синхронизации с использованием блокирующих примитивов и при определенных ограничениях на инварианты типов объектов, параллельная программа, использующая только такую блокирующую синхронизацию, может быть без потери общности представлена с использованием крупнозернистого параллелизма, который гарантированно корректно аппроксимирует реальный, мелкозернистый параллелизм в предположении корректного использования методологии владения [23]. Для поддержки серий обновлений, а также неатомарной инициализации вновь выделяемых в памяти объектов в условиях методологии с двухметочными инвариантами, все объекты расширяются специальным булевым теневым состоянием, которое отражает, находится ли соответствующий объект (с точки зрения текущего потока) в состоянии обновления. В фиксированной точке потока управления программы обновляемые объекты называются открытыми, в то время как гарантированно неизменяемые объекты называются закрытыми. Корректность использования методологии LCI, таким образом, прямо включает требование того, что все потоки управления должны работать только либо с закрытыми объектами, либо с объектами, которыми они владеют (и, как следствие, могут работать с ними эксклюзивно, в последовательном режиме). Из методологии LCI также прямо следует, что открывать объект должен только поток, который им владеет. В то же время если возможно доказать, что объект остается закрытым, он не может изменен и чтение из него корректно. Двухметочные инварианты предполагаются выполненными только для переходов между состояниями, в 54

Труды ИСП РАН, том 27, вып. 4, 2015 г..

которых соответствующие объекты являются закрытыми. Наиболее важным свойством, которое обеспечивается методологией владения, является свойство локальности, означающее, что проверки двухметочных инвариантов для каждой сери операций обновления каждого объекта в отдельности при определенных ограничениях оказывается достаточно для гарантии сохранения инвариантов во всей параллельной программе целиком. Ограничение, налагаемое на двухметочные инварианты для достижения этого свойства называется ограничением взаимной допустимости. Двухметочный инвариант (взаимно) допустим, если он рефлексивен, то есть для него выполнено следствие J(s1(s2) -» J(s2,s2) для любой пары состояний s-l и ^соответствующего объекта, и стабилен, то есть сохраняется при любом переходе, сохраняющем инварианты всех измененных объектов. Взаимная допустимость двухметочных инвариантов - это нелокальное свойство, которое в общем случае может зависеть от любого инварианта какого-либо типа объектов, но это свойство монотонно в том смысле, что будучи выполненным для какого-либо набора инвариантов, оно не может быть нарушено только лишь путем добавления в программу новых типов объектов или инвариантов. Проверка взаимной допустимости всех заданных инвариантов, таким образом, позволяет локализовать проверки сохранения этих инвариантов, каждый раз принимая в рассмотрение только инварианты объектов, непосредственно затрагиваемых при данном обновлении состояния.

В инструменте VCC используется расширение методологии владения, в котором вводится понятие асинхронно-изменяемых полей, для которых операции чтения и записи выполняются атомарно и разрешены вне зависимости от владения объектом, но только при условии, что они не выполняются одновременно с операциями последовательного обновления состояния объекта, то есть объект при обновлении остается закрытым. Любое атомарное обновление асинхронно-изменяемых полей объекта должно сохранять все его инварианты. Расширение методологии владения асинхронно-изменяемыми полями и атомарными операциями не нарушает свойства локальности всей методологии, но позволяет выразить (или специфицировать) с её помощью более широкий класс механизмов синхронизации.

3. Методология владения и ACSL

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

• В отличие от VCC, ACSL не обеспечивает и не предполагает использования какой-либо объектно-ориентированной парадигмы поверх языка С и даже не имеет достаточно высокоуровневой семантики. Однако, модуль Jessie в текущей реализации фактически уже осуще-

55

Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 4, 2015.

ствляет трансляцию исходных специфицированных C/ACSL-программ в объектно-ориентированный промежуточный язык (также называемый Jessie [24]). Таким образом, одним из первых шагов в направлении поддержки методологии владения в языке ACSL является предоставление с помощью него доступа к некоторым возможностям, доступным в промежуточном языке Jessie (или аналогичном объектно-ориентированном языке), в частности, к дополнительным предопределенным теневым полям каждого объекта, требуемым для поддержки методологии владения (например, \closed и owns).

• В VCC (и в методологии владения в целом) отсутствует прямой аналог понятия валидности указателя, принятого в языке ACSL, и доступного через конструкции \valid и \valid_read. Наиболее близкими аналогами понятия валидного указателя в методологии владения являются понятия указателя на открытый объект (которым владеет текущий поток) для неатомарных операций и указателя на закрытый объект для атомарных операций. Объединение этих случаев наиболее близко соответствует семантике предиката valid (точнее говоря, это корректное нижнее приближение этого предиката). Понятие указателя на закрытый объект или на объект, которым владеет текущий поток, аналогично корректно приближает предикат \valid_read. В целях упрощения интеграции существующих верифицированных последовательных фрагментов кода в контекст рассматриваемой методологии для параллельных программ предлагается объединить указанные близко соответствующие понятия, выразив их друг через друга в конечных специфицированных программах на языке Why3ML. При этом понятия методологии владения предлагается рассматривать как более примитивные, а предикаты valid и \valid read - как составные, выразимые через понятия методологии владения. В большинстве случаев это должно позволить части ранее верифицированного последовательного кода в параллельном контексте непосредственно, без каких-либо изменений в соответствующих спецификациях. Типичный пример такого использования - вызов функции, требующей валидности какого-либо указателя в контексте, где объект, адресуемый этим указателем открыт и его владельцем является текущий процесс.

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

56

Труды ИСП РАН, том 27, вып. 4, 2015 г..

ничениям на запись в открытые объекты (текущего процесса) и на изменение множества объектов, которыми владеет текущий процесс соответственно. Таким образом, если объект остается открытым и принадлежащим текущему процессу (фактически это соответствует последовательному доступу) на протяжении всего выполнения функции (в пре- и пост- состояниях, а также в любом состоянии, в котором управление находится в этой функции), такой объект должен быть специфицирован с помощью конструкции assigns. Когда же в результате выполнения функции объект изменяет своего владельца на текущий процесс или с текущего процесса на какой-либо другой объект (возможно, процесс), такой объект должен быть специфицирован с помощью конструкций allocates/frees соответственно. Такое соответствие может показаться неожиданным для пользователей, поэтому для конструкций allocates/frees могут быть введены более очевидные синтаксически синонимичные обозначения (например acquires/releases).

• В последней версии языка ACSL (в версии, соответствующей Frama-C Sodium-20150201 [6]) определяется два вида инвариантов типов данных - сильные и слабые инварианты. Двухметочные инварианты, лежащие в основе методологии владения, не являются ни теми, ни другими, поэтому их предлагается непосредственно интегрировать в язык ACSL. Далее в данной статье для обозначения двухметочных инвариантов типов используется ключевое слово 2state.

• Еще одним не обязательным, но весьма желательным в контексте методологии владения, расширением языка ACSL является возможность объявлять теневые структурные типы с заданными инвариантами из любой точки программного кода (а не только в глобальном контексте). Эго расширение наиболее важно для упрощения использования динамических утверждений (см. секцию 3.2).

4. Методология владения на примерах

4.1 Спин-блокитровки

Рассмотрим теперь пример достаточно простого механизма синхронизации, формализованного с использованием методологии владения. Намеренно упрощенная спецификация для механизма спин-блокировок, представленная на рис. 1, иллюстрирует предлагаемый подход к интеграции методологии владения в язык ACSL. Представленный пример в основном повторяет аналогичный пример спецификации из документации VCC [25], перенесенный на язык ACSL, однако он также демонстрирует некоторые особенности, специфичные для языка ACSL. Наиболее заметная из них - использование специально вводимого предиката \new для различения указателей на открытые и закрытые вновь выделенные объекты. Используемый в ACSL предикат fresh, следуя

57

Trudy ISP RAN [The Proceedings of ISPRAS], vol. 27, issue 4, 2015.

предлагаемой семантике для валидности указателей, должен быть выполнен в обоих этих случаях. Семантики операций закрытия вновь выделенных и ранее открытых объектов отличаются, так как требуют выполнения различных проверок инвариантов (например, инвариант counter != \o/c/(counter) —► counter = o/c/(countcr) + 1 невозможно доказать для операции закрытия после инициализации объекта). ACSL также требует явной спецификации контекстных ограничений на множество объектов, которыми владеет текущий процесс. В примере также используются вводимые встроенные примитивы \acquire и (release для изменения значений предопределенных теневых полей \owner и \owns.

volatile_owns struct spinlock { volatile unsigned int slock;

//0 ghost void *resource;

/*@ 2state type invariant

@ same_resource(struct spinlock 1) = \old(l.resource) ==

1.resource;

0*/

/*0 2state type invariant

@ ownership(struct spinlock 1) =

0 /1.slock ==> \subset(resource, \owns(&l));

0

0*/

/*0 requires \owned(obj) && \closed(obj);

0 requires \valid(l) && \new(l);

0 requires \owns(l) == \ empty;

0 frees obj;

0 ensures \closed(l);

0 ensures l->resource == obj;

0*/

void spin_lock_init(struct spinlock *1 /*0 ghost void *obj */)

{

l->slock = 0;

/*0 ghost {

0 l->resource = obj;

0 \release(obj, 1);

0 \close(l);

0 }

0*/

}

/*0 requires \closed(l);

0 allocates l->resource;

0 ensures \owned(l->resource) && \closed(l->resource);

0*/

void spin_lock(struct spinlock *1)

58

Труды ИСП РАН, том 27, вып. 4, 2015 г..

{

int stop = 0; do {

/*0 atomic (1) */ {

stop = !cmpxchg(&l->slock, 1, 0);

/*0 ghost

0 if (stop)

0 \acquire(l->resource, 1) ;

0*/

}

} while ( ! stop);

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

}

/*0 requires \closed(l);

0 requires \owned(l->resource) && \closed(l->resource);

0 frees l->resource;

0*/

void spin_unlock(struct lock *1)

{

/*0 atomic (1) */ {

l->slock = 0;

//0 ghost \release(l->resource, 1) ;

}

Рис. 1. Пример спецификации спин-блокировок.

4.2 Динамические утверждения

Так же как и пример упрощенной спецификации спин-блокировок из документации VCC, его рассмотренная ACSL-версия изначально делает не приемлемые в реальности предположения, закоючающиеся в требовании в предусловиях примитивов синхронизации выполненности предикатов \closed( 1). Проблема такого предусловия заключается в том, что неясно, как оно может быть непосредственно доказано для потока, не владеющего объектом/. Для решения этой проблемы в инструменте VCC вводится специальное понятие динамического утверждения, которое представляет собой объект определенного типа (с соответствующим набором инвариантов), специально предназначенный для того, чтобы им мог владеть некоторый поток управления и, выполняя над этим объектом операции открытия/закрытия, использовать инварианты его типа для доказательства закрытости (и, возможно, некоторых других свойств) других объектов. Для упрощения использования механизма динамических утверждений в VCC вводятся специальное предопределенное теневое поле \claim_counter, которое проверяется в операциях открытия объектов и может быть изменено только с помощью специальных конструкций вы-деления/освобождения динамических утверждений. Пример объявления типа структуры для динамического утверждения приведен на рис. 2. В этом определении используется специальный атрибут claim, который позволяет доба-

59

Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 4, 2015.

вить к типу структуры неявное поле claimed и двухметочный инвариант, который не является взаимно допустимым без учета дополнительного предусловия вида \claim counter = 0 для операций открытия объектов. Таким образом, поддержка динамических утверждений требует введения дополнительных предусловий для операции открытия объектов. Эти предусловия могут быть либо фиксированными, либо задаваемыми пользователем для каждого типа структур аналогично двухметочным инвариантам. Введение фиксированных предусловий и встроенной поддержки динамических утверждений может быть обосновано большой частотой их использования в спецификациях параллельных программ. В варианте методологии владения, реализованной в инструменте VCC, роль динамических утверждений не ограничивается использованием их для доказательства закрытости объектов, принадлежащих множеству claimed. За счет формулирования дополнительных двухметочных инвариантов динамические утверждения в инструменте VCC превращаются в аналоги проверочных утверждений, а также пред- и постусловий в условиях параллельной среды. Поэтому конструкция выделения экземпляров динамических утверждений в VCC позволяет непосредственно указывать произвольный инвариант (предикат над состоянием совокупности закрытых объектов) при создании динамического утверждения. Предполагаемый синтаксис соответствующей конструкции в языке ACSL - \сШт(тег структуры, указ, на объект_1, .., указ, на объект п, предикат). В предикате предполагается возможность добавления полей к типу структуры динамического утверждения с помощью конструкции выражение \as имя поля. Так как создание динамических утверждений выполняется для предикатов над совокупностью закрытых объектов, поля \claim_counter являются асинхронно-изменяемыми у всех типов структур. Поддержка конструкции \claim требует добавления возможности неявного объявления типов структур динамических утверждений вместе с соответствующими инвариантами, указываемыми при выделении экземпляров этих утверждений. Операции выделения динамических утверждений могут осуществляться только внутри атомарных секций, что в принципе позволяет синхронизировать операции изменения теневых счетчиков \claim counter и реальных счетчиков ссылок с помощью соответствующих инвариантов и осуществлять соответствующие операции внутри одних тех же атомарных секций.

/*0 ghost claim struct claim {

0 set<void*> claimed;

0 };

0

0 // 2state type invariant

0 // claim(struct claim c) =

0 // \forall void *o;

0 // \subset(o, c.claimed) ==>

0 // \closed(o);

0*/

Puc. 2. Пример спецификации типа структуры динамического утверждения.

60

Труды ИСП РАН, том 27, вып. 4, 2015 г..

4.3 Механизм синхронизации RCU

Read-copy-update (сокращенно RCU [18]) - это механизм синхронизации с поддержкой неблокирующих операций чтения и частично неблокирующей операции записи. В терминах механизма синхронизации RCU запись называется обновлением и осуществляется в две отдельных фазы. Первая фаза, фаза удаления, сводится к защищенному барьером синхронизации памяти атомарному обновлению значения защищенной механизмом синхронизации RCU указательной переменной на значение NULL (или другое предопределенное значение невалидного указателя), либо на значение адреса полностью и корректно инициализированного объекта (и, таким образом, готового к выполнению над ним произвольных операций чтения). Вторая фаза, фаза освобождения, состоит в эксклюзивном (обычно защищаемом блокировками) освобождении памяти, занимаемой ранее удаленным по завершению соответствующей предшествующей первой фазы устаревшим объектом. Две стадии обновления разделяются с помощью специальной блокирующей операции синхронизации, которая гарантирует, что соответствующий устаревший объект (уже удаленный, но еще не освобожденный) останется валидным и доступным для чтения до тех пор, пока все операции чтения этого объекта во всех параллельно выполняющихся потоках не будут гарантированно завершены. Для обеспечения этой гарантии операции чтения из всех защищаемых механизмом RCU указательных переменных должны быть обрамлены парой специальных ограничительных операций начала/конца критической сессии. Кроме этого, когерентность (свежесть) значений защищаемых переменных, из которых происходит чтение внутри критической секции, должна быть явно обеспечена хотя бы однажды внутри любой критической секции, причем строго до первого доступа к этим переменным внутри секции. Выполнение этого условия обеспечивается с помощью специальной операции защищенного разыменования. При выполнении описанных условий блокирующая операция, осуществляемая в ходе обновления, может просто ожидать окончания всех критических секций, оставшихся открытыми по завершении фазы удаления, что автоматически гарантирует полное завершение всех операций чтения устаревшего объекта к моменту завершения блокирующей операции ожидания. Таким образом, сущность реализации механизма синхронизации RCU заключается в предоставлении следующих пяти основных примитивов: 1) защищенная барьером операция атомарного обновления значения для первой фазы обновления (в ядре Linux соответствующий примитив называется rcuassignjointer); 2) блокирующая операция, разделяющая две фазы обновления (в Linux она называется synchronize геи); 3) операция входа в критическую секцию чтения (rcu read lock); 4) операция выхода из критической секции чтения (геи read unlock); 5) операция защищенного разыменования (rcu dereference). Реализация механизма RCU в ядре Linux позволяет для большинства процессорных архитектур сделать реализацию операций 3-5 пустой, переложив таким образом все накладные расходы на синхронизацию на операции 1 и 2. Кроме этого, фаза освобождения вместе с предшествующей ей блокирующей

61

Trudy ISP RAN [The Proceedings of ISPRAS], vol. 27, issue 4, 2015.

операцией ожидания может быть выполнена в параллельном процессе. Это обеспечивает высокую эффективность и частоту использования механизма RCU в ядре Linux [26].

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

/*@ axiomatic rcu {

@ type rcu section = integer;

0

0 2state type invariant

0 rcu secion(rcu section s) = \owned(&s);

0

0 logic struct lock *rcu_lock (void. **loc, void *obj) ;

0 predicate rcu_reclaimable(void *obj);

@ /

0

0 ghost rcu_section current_section = 0;

0 ghost set<void rcu_dereferenced = \empty;

@*/

/*0 requires current_section == 0;

0 assigns current_section;

0 ensures current_section != 0;

@*/

void rcu_read_lock(void);

/*0 requires current_section != 0;

0 assigns current_section;

0 assigns rcu_dereferenced;

0 frees rcu_dereferenced;

0 ensures current_section == 0;

0 ensures rcu_dereferenced == \empty/

0*/

void rcu_read_unlock(void);

/*0 requires rcu_lock (loc, obj) == 1;

0 requires rcu_reclaimable (obj);

0 allocates 1;

62

Труды ИСП РАН, том 27, вып. 4, 2015 г..

0 ensures \closed(l) ;

0*/

void synchronize_rcu(void /*0 ghost void **loc, void *obj, struct lock * 1 * / ) ;

/*0 requires \owned(l) && \closed(l);

0 requires l->resource == obj;

0 requires \claim_count (1) == 0;

0 trees 1;

0 ensures rcu lock(loc, obj) == 1;

0 ensures rcu_reclaimable( *loc);

0*/

void rcu_protect(void **loc, void *obj, struct lock *1);

#define rcu_assign_pointer(p, v, 1) \

{\

rcu protect(&p, v, 1) ; \

p = v; \

v;\

/*0 requires current_section != 0;

0 requires rcu_lock(loc, obj) 1= NULL;

0 assigns rcu_dereferenced;

0 allocates obj;

0 ensures obj 1= NULL ==> \closed(obj);

0 ensures rcu_dereferenced =

0 \union(\old(rcu_dereferenced), obj);

@*/

void *rcu_deref(void **loc, void *obj)

#define rcu dereference(p, c) \

((typeof(p)) rcu deref(&p, p));

Рис. 3. Упрощенная спецификация интерфейса механизма RCU.

5. Заключение

В статье предложено расширение языка спецификаций ACSL, поддержка которого реализована в наборе инструментов Frama-C-Jessie-Why3, с целью поддержки верификации параллельного кода с использованием методологии владения. В статье также рассмотрены примеры применения предложенного расширения для спецификации спин-блокировок и внешнего интерфейса механизма синхронизации RCU, широко используемого модулями ядра Linux. Предложенная формализация, однако, не была формально верифицирована.

Литература

[ 1 ]. http:/Ainuxtesting. org/astraver.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

[2] . Р. Cuoq, F. Kirchner, N. Kosmatov, V. Prevosto, J. Signoles, B. Yakobowski,

“FRAMA-C, A Software Analysis Perspective”, Proceedings of International Conference on Software Engineering and Formal Methods 2012 (SEFM’ 12), October 2012.

[3] . L. Correnson, Z. Dargaye, A. Pacalet, “WP (Draft) Manual”',

63

Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 4, 2015.

[4] . http://frama-c.com/download/frama-c-wp-manual.pdf.

[5] . Y. Moy. Automatic Modular Static Safety Checking for C Programs: Ph.D. Thesis.

Universite Paris-Sud. -2009. - January, http://www.lri.fr/~marche/moy09phd.pdf.

[6] . http://kemeis.github.io/cil/doc/html/cil/.

[7] . P. Baudin, J.-C. Filliatre, C. Marche, B. Monate, Y. Moy, V. Prevosto, “ACSL: AN-

SI/ISO C Specification Language. Version 1.7”, http://frama-c.com/download/acsl.pdf.

[8] . F. Bobot, J.-C. Filliatre, C. Marche, A. Paskevich, “Why3: Shepherd your herd of prov-

ers”, Boogie 2011: First International Workshop on Intermediate Verification Languages, 2011.

[9] . J.-C. Filliatre, A. Paskevich,“Why3 - where programs meet provers", In Programming

Languages and Systems, pp. 125-128, Springer Berlin Heidelberg, 2013.

[10] . L. De Moura, N. Bjomer, “Z3: An efficient SMT solver”', In Tools and Algorithms for

the Construction and Analysis of Systems, pp. 337—340, Springer Berlin Heidelberg, 2008.

[11] . C. Barrett, C. L. Conway, M. Deters, L. Hadarean, D. Jovanovic, T. King, A. Reynolds,

C. Tinelli, “CVC4”, In Computer aided verification, pp. 171—177, Springer Berlin Heidelberg, January, 2011.

[12] . A. Riazanov, A. Voronkov, “The design and implementation of Vampire”, In AI com-

munications, vol. 15(2, 3), pp. 91—110, 2002.

[13] . S. Schulz. “System Description: E 1.8”', In Proceedings of the 19th LPAR, Stellenbosch,

pp. 477—483, LNCS 8312, Springer Verlag, 2013.

[14] . Y. Bertot, P. Casteran, “Interactive theorem proving and program development: Coq'Art:

the calculus of inductive constructions”', Springer Science & Business Media, 2013.

[15] . S. Owre, S. Rajan, J. M. Rushby, N. Shankar, M. Srivas, “PVS: Combining Specifica-

tion, Proof Checking, and Model Checking”', In proceedings of Computer-Aided Verification '96, pp. 411—414,1996.

[16] . T. Hubert, C. Marche, “Separation analysis for deductive verification”', In Heap Analy-

sis and Verification, Braga, Portugal, March, 2007.

[17] . J.-P. Talpin, P. Jouvelot, “Polymorphic type region and effect inference”, Technical Re-

port EMP-CRI E/l 50,1991.

[18] . M. Mandrykin, A. Khoroshilov, “High level memory model with low level pointer cast

support for Jessie intermediate language”, In Programming and Computer Software, Vol. 41, No. 4, pp. 197—208, 2015.

[19] . P. E. McKenney, J. Appavoo, A. Kleen, O. Krieger, R. Russell, D. Sarma, M. Soni,

“Read-copy update”, In AUUG Conference Proceedings, p. 175,2001.

[20] . C. Flanagan, S. N. Freund, S. Qadeer, “Thread-modular verification for shared-memory

programs”, In ESOP 2002, Number 2305 in LNCS, Springer, pp. 262—277,2002.

[21] . E. Cohen, M. Dahlweid, M. Hillebrand, D. Leinenbach, M. Moskal, T. Santen, W.

Schulte, S. Tobies, “VCC: A practical system for verifying concurrent C”, In Theorem Proving in Higher Order Logics, pp. 23—42, Springer Berlin Heidelberg, 2009.

[22] . E. Cohen, M. Moskal, S. Tobies, W. Schulte, “A precise yet efficient memory model for

C”, In Electronic Notes in Theoretical Computer Science, vol. 254, pp. 85—103. 2009.

[23] . E. Cohen, M. Moskal, W. Schulte, S. Tobies, “Local Verification of Global Invariants in

Concurrent Programs”, In Computer Aided Verification, Springer Berlin Heidelberg, pp. 480—494, January, 2010.

[24] . E. Cohen, M. Moskal, W. Schulte, S. Tobies. “A practical verification methodology for

concurrent programs”, Tech. Rep. MSR-TR-2009-15, Microsoft Research, 2009. (http://research.microsoft.com/pub)

64

Труды ИСП РАН, том 27, вып. 4, 2015 г..

[25] . J.-C. Filliatre, С. Marche, “The Why/Krakatoa/Caduceus platform for deductive pro-

gram verification”, In Proceedings of the 19th International Conference on Computer Aided Verification, Lecture Notes in Computer Science, Springer, 2007.

[26] . M. Moskal, W. Schulte, E. Cohen, M. A. Hillebrand, S. Tobies, “Verifying C programs:

a VCC tutorial”', MSR Redmond, EMIC Aachen, 2012.

[27] . P.E. McKenney, S. Boyd-Wickizer, J. Walpole, “RCU usage in the Linux kernel: one

decade later”, Technical report, 2013.

65

Trudy ISP RAN [The Proceedings of ISPRAS], vol. 27, issue 4, 2015.

Towards Deductive

Verification of C Programs with Shared Data

12,3,4ду_ fflioroshilov <[email protected]>

!M. U. Martdrykin <[email protected]>

1 ISPRAS, 25, Alexander Solzhenitsyn st„ 109004, Moscow, Russia 2Lomonosov Moscow State University, 2nd Education Building, Faculty CMC, GSP-1, Leninskie Gory, Moscow, 119991, Russian Federation 3Moscow Institute of Physics and Technology, 9 Institutskiy per., Dolgoprudny, Moscow Region, 141700, Russia

4Higher School of Economics, National Research University, 20 Myasnitskaya Ulitsa, Moscow 101000, Russia

Abstract. The paper takes a look at the problem of deductive verification of Linux kernel code that is concurrent and accesses shared data. The presence of shared data does not allow to apply traditional deductive verification techniques, so we consider how to verify such code using proof of its compliance to a specification of a synchronization discipline. The approach is demonstrated on examples of spinlock specification and a simplified specification of RCU (Read-copy-update) API.

Keywords: Verification, concurrency, invariants, C programming language.

References

[1] . http://linuxtesting.org/astraver.

[2] . P. Cuoq, F. Kirchner, N. Kosmatov, V. Prevosto, J. Signoles, B. Yakobowski,

“FRAMA-C, A Software Analysis Perspective”, Proceedings of International Conference on Software Engineering and Formal Methods 2012 (SEFM’12), October 2012.

[3] . L. Correnson, Z. Dargaye, A. Pacalet, “WP (Draft) Manual”',

[4] . http://frama-c.com/download/frama-c-wp-manual.pdf.

[5] . Y. Moy. Automatic Modular Static Safety Checking for C Programs: Ph.D. Thesis.

Umversite Paris-Sud. - 2009. - January, http://www.lri.fr/~marche/moy09phd.pdf.

[6] . http://kemeis.github.io/cil/doc/html/cil/.

[7] . P. Baudin, J.-C. Filliatre, C. Marche, B. Monate, Y. Moy, V. Prevosto, “ACSL: AN-

SI/ISO C Specification Language. Version 1.7”, http://frama-c.com/download/acsl.pdf.

[8] . F. Bobot, J.-C. Filliatre, C. Marche, A. Paskevich, “Why3: Shepherd your herd of prov-

ers”, Boogie 2011: First International Workshop on Intermediate Verification Languages, 2011.

[9] . J.-C. Filliatre, A. Paskevich,“Why3 - where programs meet provers", In Programming

Languages and Systems, pp. 125-128, Springer Berlin Heidelberg, 2013.

66

Труды ИСП РАН, том 27, вып. 4, 2015 г.

[10] . L. De Mourn, N. Bjomer, “Z3: An efficient SMT solver”', In Tools and Algorithms for

the Construction and Analysis of Systems, pp. 337—340, Springer Berlin Heidelberg, 2008.

[11] . C. Barrett, C. L. Conway, M. Deters, L. Hadarean, D. Jovanovic, T. King, A. Reynolds,

C. Tinelli, “CVC4”, In Computer aided verification, pp. 171—177, Springer Berlin Heidelberg, January, 2011.

[12] . A. Riazanov, A. Voronkov, “The design and implementation of Vampire”, In AI com-

munications, vol. 15(2, 3), pp. 91—110,2002.

[13] . S. Schulz. “System Description: E 1.8”', In Proceedings of the 19th LPAR, Stellenbosch,

pp. 477—483, LNCS 8312, Springer Verlag, 2013.

[14] . Y. Bertot, P. Castcran, ‘interactive theorem proving and program development: Coq'Art:

the calculus of inductive constructions”', Springer Science & Business Media, 2013.

[15] . S. Owre, S. Rajan, J. M. Rushby, N. Shankar, M. Srivas, ‘TVS: Combining Specifica-

tion, Proof Checking, and Model Checking”', In proceedings of Computer-Aided Verification'96, pp. 411—414,1996.

[16] . T. Hubert, C. Marche, “Separation analysis for deductive verification”', In Heap Analy-

sis and Verification, Braga, Portugal, March, 2007.

[17] . J.-P. Talpin, P. Jouvelot, “Polymorphic type region and effect inference”, Technical Re-

port EMP-CRI E/l 50,1991.

[18] . M. Mandrykin, A. Khoroshilov, “High level memory model with low level pointer cast

support for Jessie intermediate language”, In Programming and Computer Software, Vol. 41, No. 4, pp. 197—208,2015.

[19] . P. E. McKenney, J. Appavoo, A. Kleen, O. Krieger, R. Russell, D. Sarnia, M. Soni,