TMPA-2013 Conference: Verification of Parallel Programs – Current Stage and Perspectives

Верификация
параллельных программ:
современный этап и перспективы
Юрий Глебович Карпов
Санкт-Петербургский
Политехнический университет
karpov@dcn.icc.spbstu.ru

Ю.Г.Карпов ТМРА 2013 Кострома 2
Проблема
 Компьютеры – повсюду Ubiquitous computing
(вездесущие вычисления)
ИТ проникли во все сферы жизни современного общества.
Раньше компьютер был компьютером, а телефон – телефоном, и
любой мог отличить одно от другого. Cейчас и компьютер – не только
компьютер, и телефон – не только телефон … (A.Tanenbaum)
 Эра параллельного программирования
Последовательные программы имеют очень узкое применение.
Встроенные системы программного управления обычно параллельны.
Многоядерные чипы, встроенные бортовые СУ -> требуются
технологии разработки параллельного ПО, чтобы оно выполняло
нужные функции
“multicore processors are bringing parallelism to mainstream of computing”
 Параллельные программы полны ошибок
Параллельные программы непостижимы для человеческого мозга:
даже простейшие программы трудно понять.
Как следствие - они очень часто неправильны, содержат ошибки

Пример параллельной программы: частично
корректна, но тотально некорректна
Параллельная программа разделения множеств (Э. Дейкстра)
все наименьшие собираются в S, все наибольшие – в L:
Small::
mx := max(S); α! mх; S := S - { mx };
β? x; S := S ∪ { x }; mx := max(S);
while mx > x
do
α! mx; S := S - { mx };
β? x; S := S ∪ {x}; mx := max(S);
od
Large::
α?y; L := L ∪ { y }; mn := min( L );
β! mn; L := L - {mn}; mn:=min( L );
while mn < y
do
α? y; L:=L ∪ {y}; mn := min( L );
β! mn; L:=L - {mn}; mn := min( L )
od
8
14
9
7 146
23
15
134
54
9 46
6
66
Small:: Large::
S L
Network
α
β
Карпов Ю.Г. Анализ корректности параллельной программы разделения множеств //
Программирование, 1996, N6,
Найдите ошибку в || программе, содержащей 2 процесса по 5 строк

Программа подсчета числа автомашин на мосту
Process A::
…
N++
…
Process B::
…
N--
…
Ошибка в || программе из одной строки???
A1. N -> RA
A2. RA+1 -> RA
A3. RA -> N
B1. N -> RB
B2. RB - 1-> RB
B3. RB -> N
Теоретически
может насчитать
все, что угодно
A1, A2, A3, B1, B2, B3
A1, A2, B1, B2, B3, A3
B1, B2, A1, A2, A3, B3
Тестированием найти
ошибку невозможно!!

Ошибки параллельных программ
 Системы программного управления строятся из параллельных
взаимодействующих модулей. Ошибки в них часто являются
критическими
 Некорректные параллельные программы работают правильно “почти
всегда”. Они могут годами сохранять ошибки, проявляющиеся после
долгой эксплуатации как реакция на возникшую специфическую комбинацию
многочисленных факторов, в частности, непредсказуемых скоростей
выполнения отдельных процессов в параллельных программах
“Существует обширный печальный опыт того, что
параллельные программы упорно сопротивляются
серьезным усилиям по выявлению в них ошибок”
S. Owicki, L. Lamport “Proving liveness properties of concurrent programs”, ACM
TOPLAS, N4, 1982

Миллионы сообщений об ошибках в ОС Windows
 По признанию Майкрософта, в ОС Windows остаются тысячи
ошибок!
 Июнь 2013: Microsoft анонсировала программу премирования
пользователей, отыскавших уязвимости в предварительной версии
операционной системы Windows 8.1. Тем, кто обнаружит ошибку или
уязвимость, обещано выплатить до $100 000.
Можно ли поставить ОС Windows на спец компьютер, управляющий
атомной электростанцией?
70 млн
документов об
ошибках в
Windows

СМИ о программных ошибках – каждый день
 Апрель, 2010. Авария в Мексиканском заливе: возможна ли программная
ошибка? Don Shafer, Phillip Laplante. The BP Oil Spill: Could Software be a Culprit?
IEEE IT Pro September/October 2010, IEEE, 2010. ... Не могла ли одной из причин
бедствия стать ошибка в программном обеспечении?
 Вoing 757, 1995 г (рейс из Майами в Кали, Колумбия ). Ошибка в одном
символе в Flight Management System привела к катастрофе. Погибли 159 чел
 08.12.2010 — Японский зонд «Акацуки» не смог выйти на орбиту Венеры
Из-за ошибки в бортовой СУ космический исследовательский аппарат «Акацуки»,
запущенный Японией для исследования Венеры, не смог выйти на орбиту планеты
 06.12.2010. “Cпутники ГЛОНАСС и ракету “Протон-М” утопили программисты”.
Ракета-носитель «Протон-М» со спутниками «Глонасс-М» отклонились от заданного курса
из-за допущенных ошибок в математическом обеспечении (основная причина -
неправильно написанная формула в документации на заправку разгонного блока)
 2.09.88 г. Связь с советской АМС "Фобос-1" прервалась из-за ошибочной
команды, посланной с Земли. АМС потеряна, где-то летает сама по себе

Ошибки во встроенных программных системах
автомобильной индустрии
 2010. Toyota отозвала с рынков >8 млн проданных автомобилей из-за
неисправности педали газа и дефекта ПО тормозной системы. Это обойдется
ей в $2 млрд. Глюк автомобилей Toyota стал причиной не менее 5 смертей.
 Акио Тойда, президент компании Тойота, 24.02.2010 выступил в Конгрессе
США и принес извинения за проблемы, связанные с качеством автомобилей
 Эксперты: проблемы возникли из-за перехода автомобильной индустрии на
программные системы в критически важных функциональных узлах
 “Основная проблема именно в компьютерной системе управления, в
которой не было предусмотрено экстренное торможение: педаль тормоза
просто не срабатывала, когда сенсор акселератора командовал
автомобилю разгоняться
 В 2009 г. В США производителями отозвано 19 млн автомобилей из-
за ошибок в программах и электронике

Ошибки в критических инфраструктурных системах
http://www.osp.ru/os/2009/03/8158133/
 Блэкаут на северо-востоке США (август 2003 г.): из-за ошибки в
многозадачной программе мониторинга возникло переполнение буферной
памяти. Система попала в бесконечный цикл. Операторы остались без
актуальной информации о состоянии энергосистемы. Если бы
оперативная информация о состоянии энергосистемы была доступна,
оператор смог бы предотвратить каскадные сбои и минимизировать
убытки.
 Сброс 4% нагрузки мог спасти ситуацию. Ущерб ~ 10$ млрд
www.icfi.com/Markets/Energy/doc_files/blackout-economic-costs.pdf

Боевые потери США в Иракской войне
 25.02.91. Операция “Буря в пустыне”: ошибка в системе управления Patriot
помешал перехватить иракскую ракету Scud, выпущенную по военной
базе Дахран в Саудовской Аравии. Ракета достигла цели, в результате
чего погибли 28 американских солдат и еще около 100 человек получили
ранения (www.fas.org/spp/starwars/gao/im92026.htm).
(Patriot - мобильная система противоракетной обороны США , оснащаемая ракетами
класса «земля-воздух» и предназначенная для защиты от самолетов, крылатых
ракет и баллистических ракет ближнего радиуса действия)

В NASA признали потерю Deep Impact
 Последний успешный сеанс связи с Deep Impact состоялся 8 августа
2013, после чего контакт с зондом был потерян. По оценкам
инженеров NASA, причиной обрыва связи стали ошибки в ПО, из-за
чего зонд потерял ориентацию в пространстве
 Deep Impact был запущен в январе 2005 года. Его основная миссия
заключалась в исследовании кометы Темпеля; она успешно была
завершена спустя полгода после запуска
21.09.2013. Специалисты NASA объявили о прекращении попыток
восстановить связь с исследовательским зондом Deep Impact

Ю.Г.Карпов Верификация 12
Needham-Schroeder протокол
аутентификации (1978)
 КАК убедиться в том, что собеседник является тем, за кого он себя выдает?
 Только если он продемонстрирует знание СЕКРЕТА, известного только ему
 NS протокол решает эту проблему с исп публичного и секретного ключей. После
установления соединения и удостоверения, кто есть кто, собеседники могут установить
сессию с секретным ключом!! Широко использовался (Kerberos основан на нем)
1.〈 А, NA 〉PK(В)
2.〈 NA, NB 〉PK(А)
3.〈 NB 〉PK(В)
1. Alice генерирует nonce NA, шифрует
сообщение публичным ключом PK(B), и
посылает по открытому каналу.
NA - первая половина “секрета”,
А - идентификация отправителя
2. Только Bob может прочитать первое
сообщение. Он генерирует свой секрет -
nonce NB, шифрует сообщение ключом
PK(А), и посылает NA и NB.
То, что в сообщении присутствует NA,
убеждает Alice, что это Bob прислал –
только он мог дешифровать первое
сообщение. Она принимает NA, NB как
общий секрет и уверена, что установила
связь с В
3. Alice отсылает NB, зашифрованное
публичным ключом PK(В).
То, что в сообщении присутствует NB,
убеждает Bob, что это Alice прислала –
только она могла дешифровать второе
сообщение с его, Боба, nonce.
Поэтому Bob также принимает NA и NB
как общий секрет и уверен, что
установил связь с А

Несет ли программист ответственность за потери
человеческих жизней?
Программирование является единственной областью
инженерной деятельности,
где разработчик не отвечает за качество своей работы
Обычно ПО имеет 10-15 ошибок на 1000 строк кода,
ПО высокого качества – 3 ошибки на 1000 строк кода
Современное ПО содержит миллионы строк кода,
уже сданные программы наполнены ошибками
SOFTWARE HORROR STORIES: http://www.cs.tau.ac.il/~nachumd/horror.html
Collection of Software Bugs: http://www5.in.tum.de/~huckle/bugse.html
Worst software defects in history:
http://cristianpocovnicu.wordpress.com/2011/03/22/worst-software-defects-in-history/
Википедия: http://en.wikipedia.org/wiki/List_of_software_bugs
Ужасы из-за ошибок ПО - в Интернете:

Конфуз с голосованием на выборах в Думу
4 декабря 2011
Σ 146.47%
Прооиски
режима?

Конфуз с голосованием на “Эхе Москвы” 24.09.2011
http://www.echo.msk.ru/programs/interception/814452-echo/
 А.В.Венедиктов:
“Подвисает система голосования...
У меня возникает 111% ...”
За Путина
хП:=0;
while !Stop
do
wait call_1;
xП ++
od
За Путина:
111%
За Медведева
хМ:=0;
while !Stop
do
wait call_2;
xМ ++
od
Σ
while !Stop
do
xΣ :=xП+хМ
od
%П
while !Stop
do
PП :=xП / xΣ
od
%М
while !Stop
do
PМ :=xМ / xΣ
od
Параллельная композиция процессов:
Эта система параллельных процессов
может выдать любой процент!!

Свойства
системы
Свойства
системыСистемаСистема
Верификация – метод повышения качества
программ
Процедура
проверки
Спецификация
системы
(формальная
модель)
требований
(на формальном
языке)
 Верификация - формальное доказательство того, что программная
система удовлетворяет формально определенным требованиям
Формально доказать
можно только нечто
формально
определенное

Основные подходы к верификации программ
 Алгебры процессов
 Дедуктивная верификация - метод Флойда-Хоара

18
Algebra of Communicated Processes – ACSR Laws
 Законы бисимуляции ACSR (Algebra of communicated shared resources, 1995)
Ю.Г.Карпов ТМРА 2013 Кострома

19
Пример доказательства корректности дедуктивным
методом Флойда-Хоара
 Программа находит произведение К=m×n с помощью сложений
НАЧАЛО
КОНЕЦ
i = m данет
K := 0;
i := 0;
K:= K + n;
i := i + 1;
Т1: [ m,n∈N ∧ m>0 ∧ K=0 ∧ i=0 ] ⇒ [ K = i × n ]
Т3: [ ( K-n = (i -1)×n ) ∧ (i -1 ≠ m) ] ⇒ [ K = i ×n ]
Т2: [ ( K=i×n) ∧ (i= m) ] ⇒ [ K= m×n ]
Доказательство
корректности программы
требует доказательства
трех теорем
{ A :: K = i×n }
Инвариант цикла:
при каждом попадании в эту точку
К=i×n
{R:: K=m×n}В конце программы должны получить
желаемый результат
{I:: m,n∈N; m≥0}В начале программы - ограничения
на исходные данные

Пример дедуктивной верификации ядра реальной
ОС
Сообщение СМИ 01.10.2009
 Research Centre of Excellence компании NISTA (Australia) объявил о
завершении работы по формальному доказательству корректности
ядра ОС с помощью интерактивной системы доказательства теорем
Isabelle
 Руководитель работы Dr. Klein:
“Этот экстраординарный результат открывает путь к разработке
нового поколения ПО с беспрецедентным уровнем надежности. Это
одно из самых длинных из когда-либо выполненных формальных
доказательств с помощью формальных средств theorem-proving”

Оценка сложности доказательства ОС Secure
Embedded L4 microkernel дедуктивным методом
Построение доказательства ядра ОС L4
~ 60 человеко-лет работы
Проверка 10 строк кода – 1 чел-месяц работы верификатора
Cложность доказательства в 30 раз выше сложности кода;
одна строка кода - ~ 1 страница доказательства
Аллен Эмерсон о дедуктивной верификации: “мы писали 15-страничный
отчет о том, что программа на полстраницы корректна”
 Трудозатраты: 4 года работы группы из 12 исследователей, PhD студентов
и нескольких других работников
 Объем: доказанная ОС содержит
7,500 строк C code.
 Сложность доказательства:
10,000 промежуточных теорем,
200,000 строк доказательства

22
Выводы
• До последнего времени методы верификации могли быть
применены для доказательства корректности только “toy examples”
 нотация сложна и неясна, ошибки встречались и в доказательствах
 методы не масштабируемы (not scalable), требовали огромных усилий
 программные инструменты неадекватны и трудны в использовании;
верификация проводилась интерактивно
 требовалась высокая квалификация для выполнения и спецификации,
и анализа

"Практики! Опасайтесь фанатиков формальных методов"
R. L. Glass, САСМ, 2004 (редактор J. of Systems and Software)

Model checking - прорыв в верификации
~ 20 лет назад – качественный прорыв в области
верификации дискретных систем
Разработан метод model checking, основанный на
изящных формальных моделях

Что такое Model checking?

Fq – q случится когда-нибудь в будущем
t
q
t |= Fq
Gq – q всегда будет выполняться в будущем
t
q
t |= Gq
Формализация требований к программе.
Использование модальностей. Tense Logic (A.Prior 1950-
е)
pUq – q случится в будущем, а до него
непрерывно будет выполняться р
t |= pUq
t
p
q
Хq - q выполнится в следующий момент
t
q
t |= Xq
t |= Ф : формула Ф истинна в момент времени t
Рq – q случилось когда-то в прошлом
t
q
t |= Pq

Примеры формализации высказываний в Tense
Logic
 Мы придем к победе коммунистического труда!
F Коммунистический_труд_победил!
 Ленин – жил, Ленин – жив, Ленин – будет жить (В.В.Маяковский)
P G Ленин_жив
 Сегодня он играет джаз, а завтра Родину продаст (В.Бахнов)
G(Он_играет_джаз ⇒ FX Он_продает_Родину)
 Я когда-нибудь умру ...
Я_жив ∧ F¬Я_жив ∧ G ( ¬Я_жив ⇒ G ¬ Я_жив )
 Любой запрос к ресурсу будет висеть до его подтверждения либо отклонения
G(Request ⇒ Request U (Reject ⊕ Confirm ) )
 Между моментом, когда процесс А изменяет значение переменной, и
моментом, когда процесс В читает это значение , оно должно быть
вытолкнуто из кэша процесса А:
G ( Update_A ∧ F Read_B ⇒ ¬Read_B U Flush_A)


LTL в дискретном времени – А. Пнуэли (1977)
На всей цепочке выполняются формулы p, q, qU(r∧q), - они истинны в w0
Семантика “возможных миров” Лейбница, в каждом свое понимание истинности:
В каждом мире произвольная логическая формула истинна, либо нет:
Это же справедливо и для произвольной темпоральной формулы:
w0
р=true
q=true
r=false
w1
р=false
q=true
r=true
w2
р=false;
q=false;
r= true
...
wn
р=false;
q=false;
r= true
...
......
w0 w1 w2
p, q, ~r,
~(q⇒r),
~(r&~q)
wn
~p, q, r,
q->r,
~(r&~q)
~p, ~q, r,
q->r,
r&~q
~p, ~q, r,
q->r,
r&~q
......
w0 w1 w2
p, q
~(q->r),
~(r&~q),
qU(r ∧q),
FGr
wn
~p, q, r,
q->r,
~(r&~q),
qU(r ∧ q),
FGr
~p, ~q, r,
q->r,
r&~q,
~qU(r∧q),
FGr
~p, ~q, r,
q->r,
r&~q,
~qU(r ∧q),
FGr
Модель времени – последовательность целых (вчера, сегодня, завтра, …)Модель времени – последовательность целых (вчера, сегодня, завтра, …)

Linear Temporal Logic (LTL) – Amir Pnueli (1977)
 Логика LTL – темпоральная логика линейного времени –
утверждения о свойствах бесконечных вычислений
 Формула ϕ LTL это :

атомарное утверждение (атомарный предикат) p, q, ...,

или Формулы, связанные логическими операторами ∨, ¬

или Формулы, связанные темпоральными операторами U, X
• Модальностей прошлого в LTL нет
Выводимые темпоральные операторы :
F ϕ = true U ϕ
G ϕ = ¬F ¬ ϕ
Грамматика: ϕ ::= p | ϕ ∨ ϕ | ¬ ϕ | X ϕ | ϕ U ϕ
LTL
к логике высказываний
добавлены только два
модальных оператора:
Until и NextTime
Базис LTL = {¬, ∨, U, X }
s0
p, q q, r r
s1 s2
... r
sn
...

LTL и спецификация свойств дискретных систем
s0
t0
s1 s2
...
sn
...
t1 t2 tn
Формулы LTL интерпретируются на вычислениях - бесконечных
цепочках состояний системы с неделимыми переходами:
s0
p, q q, r r
s1 s2
... r
sn
...
Атомарные предикаты - базисные свойства процесса в состояниях:
p, q,
qUp
q, r
Gr
r,
Gr
... r
Gr
...
Производные темпоральные формулы в состояниях – это свойства
вычисления в будущем, определяющие динамику процесса:
qUp – выполняется на вычислении
Gr – не выполняется на вычислении

Линейное и ветвящееся время
а
b,аc
d
а
c
d b,аb,а
Cтруктура Крипке –
система переходов с
помеченными
состояниями и
непомеченными
переходами
Развертка структуры
Крипке определяет
бесконечные
цепочки состояний -
возможные
ВЫЧИСЛЕНИЯ
Каждое состояние может иметь не одну, а множество цепочек – продолжений,
и является корнем своего дерева историй (вычислений)
Но как понимать формулы LTL: Gp, pUq, … в состоянии? Для какого пути?
Ввести “кванторы пути”
Е ϕ ≡ “существует такой путь из данного состояния, на котором ϕ истинна”
А ϕ ≡ “для всех путей из данного состояния формула пути ϕ истинна”
Очевидно, А ϕ ≡ ¬Е ¬ϕ
Как конечным образом задать бесконечные вычисления?Как конечным образом задать бесконечные вычисления?
cUb?

Темпоральная логика ветвящегося времени
 AGAF Restart
 из любого состояния при любом функционировании системы
обязательно вернемся в состояние рестарта
 ¬EF( int >0.01)
 не существует такого режима работы, при котором интенсивность
облучения пациента превысит 0.01 радиан в сек
 AG ( req ⇒ (req U ack))
 во всех режимах после того, как запрос req установится, он никогда не
будет снят, пока на него не придет подтверждение
 E[ p U A [q U r] ]
 cуществует режим, в котором условие p будет истинным с начала
вычисления до тех пор, пока q не станет непрерывно активным до
выполнения условия r
Темпоральные логики: прорыв в формализации и понимании
требований к поведению параллельных систем

Пример свойства, выраженного формулой логики CTL
 Любой грешник всегда имеет шанс вернуться на путь истинной веры
Всегда, куда бы мы ни попали в нашей жизни (AG), существует такой путь, что
на нем в конце концов обязательно попадем (ЕF) в состояние, с которого идет
путь (EG) ‘истинной веры’
AG EF EG ‘истинная_вера ’

Спецификация свойств поведения дискретных
схем
σ0 ¬⊧ p
σ0 F ¬⊧ q
σ0 G(⊧ p→q)
σ0 q U p⊧
σ0 FG(¬p⊧ ∧q)
p,q p qq q …qp q qqq
σ:
σ:

Структура Крипке синхронных схем c памятью
 Переходы выполняются в каждом такте
 Задержка: логическая схема - 0, память – 1
 Два начальных состояния
XOR
OR
NOT
r
p
q
p
q
r
p=0,
r=0,
q=1
p=1,
r=0,
q=0
p=0,
r=1,
q=0
10
p=1,
r=1,
q=1
1
0
1
0
0 1
q=¬(p⊕r)
q p
r p, r,
q
Структура Крипке:

Структура Крипке как модель программы с конечным
числом состояний
Состояние программы – вектор значений ее
переменных И метки (рс)
Переходы – изменение операторами значений
переменных программы
Пусть атомарные утверждения,
ИНТЕРЕСУЮЩИЕ НАС:
а=х>y; b=|x+y|<3
begin
х:=0; у:=1;
while x+z < 5 do
{ x:=5;
if z=1 then y:=x+1;
x:= -2; y:=1;
}
y:= x*y-5; x:=5;
end
х=0
У=1
х=5
У=-7 х=-2
У=1
х=5
У=6
х=5
У=1
х:=0; у:=1;
х:=5;
y:=x+1;
х:=-2;
у:=1;
b
a
b
ba
b
Если все переменные могут
принимать конечное число
значений, то граф конечен

Свойства
системы
Свойства
системыСистемаСистема
Общая схема верификации Model checking
Спецификация системы
(формальная модель)
Процедура проверки
Спецификация требований
(формальный язык)
Формула темпоральной
логики
Структура Крипке
Формально доказать
можно только нечто
формально
определенное
Да, система удовлетворяетДа, система удовлетворяет
спецификацииспецификации
Нет, система НЕ удовлетворяетНет, система НЕ удовлетворяет
спецификацииспецификации
КОНТРПРИМЕРКОНТРПРИМЕР
Model checker

Model checking – проверка того, является ли данная
структура Крипке моделью темпоральной формулы
Логика высказываний
F=(¬p ∨ q ) ⇒ r
И
Л
<И, И, Л>
<Л, И, Л>
<Л, Л, И>
Интерпретация <Л, Л, И> - модель формулы F
Темпоральная логика
Ф=AG[(p ⇒ E(¬q U r )]
И
Л
Интерпретации PL –
наборы значений
переменных <p, q, r>
К2
К1
К3
Интерпретации TL –
структуры Крипке,
в каждом состоянии
которых свой набор
значений
переменных <p, q, r>
Интерпретация К1 - модель формулы Ф
Model checking – проверка того,
является ли К моделью Ф

Примеры использования подхода
 Cambridge ring protocol
 IЕЕЕ Logical Link Control protocol, LLC 802.2
 фрагменты больших протоколов XTP и TCP/IP
 отказоустойчивые системы, протоколы доступа к шинам,
протоколы контроля ошибок в аппаратуре, ... ...
 криптографические протоколы
 протокол Ethernet Сollision Avoidance
 DeepSpace1 (NASA) - после тщательного тестирования и
сдачи системы были найдены критические ошибки, которые,
по мнению экспертов, обязательно привели бы к аварии в
полете
С помощью Model checking были найдены ошибки во
многих критических программных системах

Пример: отчет фирмы Rockwell Collins 2007г.

Контрпример:
ВОТ КАК ПРОГОЛОСУЮТ!
Система процессов P1 || P2 || P3 || P4 || P5
Проверка свойства :
“За Путина не могут проголосовать 300%”
A G (pп < 300)
Верификация ПО голосования с
помощью верификатора SPIN

Пример: верификация системы управления
электродвижением гидрофизического судна “Вайгач”
Функции системы управления:
 контроль состояния судовых электростанций
и обработка критических ситуаций
 автоматическая балансировка нагрузки между
двумя судовыми электростанциями
 обработка команд вахтенного капитана
50
дизель генератор ГА
пульт
управления
Управление
двигателями Engine
Система
управления
В оттестированной и сданной заказчику
системе найдено несколько критических
ошибок, которые проявились при ходовых
испытаниях корабля на Белом море
Проект научной группы
Петербургского Политеха

51
Атака на криптопротокол аутентификации Needham-
Schreder
Bob думает, что он говорит с Alice, а он говорит с Intruder!
А В
1.〈 А, NA 〉PK(В)
2.〈 NA, NB 〉PK(А)
3.〈 NB 〉PK(В)
1:<A, NA>PK(I)
2:<A, NA>PK(B)
3:<NA, NB>PK(A)4:<NA, NB>PK(A)
5:<NB>PK(I)
6:<NB>PK(B)
Alice BobIntruder

Ю.Г.Карпов 52
Найденная атака в A||B||I
1
2
3
4
5
6
1. А начинает взаимодействовать с I как с
партнером, посылая ему <A, NA>PK(I)
2. I получает NА – секрет А. Он маскируется под А,
используя секрет, полученный от А: посылает
сообщение <A, NA>PK(B) к В. В его дешифрирует и
считает, что это сообщение пришло от А
3. В считая, что говорит с А, посылает в ответ
сообщение <NA, NB>PK(A), которое зашифровано
открытым ключом А. I получает это сообщение.
Поскольку оно закодировано открытым ключом
А, I не может декодировать это сообщение
сам, но может переслать его А как бы от себя
4. Получив это сообщение, А видит свой NA,
считает, что обмен закончился успешно, и
посылает секрет В - <NB>PK(I) - своему партнеру,
агенту I, полагая, что им установлена связь с I
5. Это сообщение закодировано ключом для I и
содержит NB. Поэтому агент I может его
декодировать, получив секрет В - nonceB
6. I посылает этот NВ агенту В, который тоже
удовлетворен, считая, что установил связь с А,
но в действительности – связь с I
1: 2:
3:4:
5: 6:
ТМРА 2013 Кострома

Success Story.
Транзакционная память в многоядерных процессорах
Транзакционная память – один из способов, позволяющих избежать
проблем синхронизации процессов над общей памятью
 Многоядерные процессоры вывели параллельное
программирование и связанные с ним проблемы ошибок в
параллельных программах “в народные массы”
 Как решать проблемы ошибок синхронизации параллельных
программ в многоядерных процессорах?
ядро 2ядро 1 ядро n
память
... ядро 2ядро 1 ядро n
память
...
протокол транзакционной памяти

“Оконный” алгоритм транзакционной памяти
 Damien Imbs, и Michel Raynal в 2009 г. предложили
оконный алгоритм транзакционной памяти вместе с
аналитическим доказательством его корректности
 CV профессора Мишеля Райнала:
 Michel Raynal - a professor of computer science since 1981.
At IRISA (CNRS-INRIA-University joint computing research
laboratory located in Rennes), he founded a research group on
Distributed Algorithms in 1983.
 His research interests include distributed algorithms, distributed
computing systems and dependability. His main interest lies in
the fundamental principles that underlie the design and the
construction of distributed computing systems. He has been
Principal Investigator of a number of research grants in these
areas
 Professor Michel Raynal has published more than 95 papers in
journals (JACM, Acta Informatica, Distributed Computing, etc.);
and more than 195 papers in conferences (ACM STOC, ACM
PODC, ACM SPAA, IEEE ICDCS, IEEE DSN, DISC, IEEE
IPDPS, etc.). He has also written seven books devoted to
parallelism, distributed algorithms and systems (MIT Press and
Wiley).

Success Story. Ошибка в STM протоколе
 Imbs D.; Raynal M. Software Transactional Memories: an Approach for
Multicore Programming. LNCS, 5698, 2009
 Эта работа была дана студенту 4 курса Петербургского Политеха Алексею
Беляеву для проверки протокола в рамках его НИРС
 Студент – построил модель протокола транзакционной памяти,
- описал требования к протоколу формулой темпоральной логики,
- использовал систему верификации SPIN
- нашел в протоколе ошибку

Выводы
 Даже опытные профессионалы могут допустить ошибки в
разрабатываемых ими параллельных программах
 Нельзя полагаться на доказательства корректности параллельных
программ на основе рассуждений, как это было сделано в работе
проф. М.Райнала
 Даже студент, используя технику Model checking, может найти
ошибки в достаточно сложной параллельной программе,
разработанной профессионалами

Состояние области “Верификация управляющего
ПО”
 Никаких доказательств и логического вывода
 Эффективность
 Контрпримеры, выдаваемые верификатором при нахождении
ошибки, можно использовать для диагностики ошибок
 TL легко выражают многие проблемы параллельных процессов
 В ведущих фирмах методы верификации аппаратуры и программ на
основе Model checking разработаны до индустриальной технологии

Премия Тьюринга АСМ
21 июня 2008 г премия Тьюринга была вручена трем создателям
техники MODEL CHECKING, внесшим наиболее существенный вклад
Edmund M. Clarke (CMU),
E. Allen Emerson (U Texas, Austin),
Joseph Sifakis (Verimag, France)
“за их роль в превращении метода Model checking в
высокоэффективную технологию верификации, широко
используемую в индустрии разработки ПО и аппаратных средств”
ACM President Stuart Feldman :
“Это великий пример того, как технология, изменившая
промышленность, родилась из чисто теоретических исследований”

59
Обучение верификации
Изучение верификации методом
Model checking даёт инженеру
теорию,
алгоритмы,
элементы технологии,
инструментарий
с помощью которых он может проверять
корректность нетривиальных
параллельных и распределенных программ

Материализация абстрактных понятий
 Формализмы, на которых основан метод Model Checking:
 темпоральные логики
 линейное и ветвящееся время
 структуры Крипке
 недетерминированные автоматы Бюхи
 бесконечные множества бесконечных цепочек (ω-языки)
 синхронная и асинхронная композиция автоматов
 неподвижные точки операторов на решетках предикатов ...
 Все эти абстракции, которые и представить себе нельзя, привели к
разработке мощной техники верификации, которая стала частью
промышленной технологии разработки критического ПО и аппаратуры
 Model checking - “реабилитация формальных методов”

Необходимость формальных методов
“Формальные методы должны стать частью образования каждого
исследователя в области информатики и каждого разработчика
ПО так же, как другие ветви прикладной математики являются
необходимой частью образования в других инженерных областях.
NASA Report 4673, “Formal Methods and Their Role in Digital System Validation
for Airborne Systems”
В области разработки ПО необходимые разделы прикладной математики –
это формальные методы, на которых основывается верификация:
формальная логика,
теория автоматов,
теория алгоритмов

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

Композициональность: доказательство свойств всей системы
на основе свойств отдельных компонент системы
Одно из направлений: Rely - Guarantee
Композициональность: метод определения свойств сложных
структур через свойства составляющих их подструктур и правил их
композиции

Идеи Эдсгера Дейкстры:
Correctness by checking vs. Correctness by construction
 Эдсгер Дейкстра:
вместо того, чтобы программу СНАЧАЛА
разрабатывать, а ПОТОМ пытаться доказать ее
правильность,
программу нужно сразу строить корректной
 Программа должна выводиться строго логически из
точно сформулированной спецификации, а не
только исходя из опыта и общих соображений
В книге “Дисциплина программирования” Э.Дейкстры приведено
множество изящных примеров такого подхода к разработке
“Этот труд, несомненно, будет признан одним из выдающихся достижений в
разработке новой интеллектуальной дисциплины – программирования”
Антони Чарльз Хоар

Ю.Г.Карпов Верификация. Model checking 65
Разработка корректных программ (Э.Дейкстра)
“Голландский национальный флаг” – построить программу сортировки
массива из трех типов объектов – “красных”, “белых” и “синих”, которые
должны в результате стоять именно в этом порядке. Программа должна
справляться со всеми случаями вырождения: отсутствием одного или
нескольких цветов
Как подойти к разработке программы?
Выбрать ИНВАРИАНТ!
неотсортированные
исходный массив
результирующий массив
промежуточный массив
Крайними состояниями инварианта являются исходный и результирующий массивы

Формализация инварианта
A ≡ [ ∀i: (1≤i<к) ] M[i] - красный
& [ ∀i: (б<i≤с) ] M[i] - белый
& [ ∀i: (с<i≤N) ] M[i] - синий
& [ ∀i: (к≤i≤б) ] M[i] - неотсортированный
& (к≥1) & (б≤с) & (с≤N)
Очевидно, что:
A & (к>б) ⇒ массив M отсортирован
(массив неотсортированных пуст)
Разработка программы сводится к построению цикла, который уменьшает зону
неотсортированных элементов, но при этом сохраняет инвариант
begin
I = { [∀i: (1≤i≤N) ] M[i] - неотсортированные}
к,б,с:=1,N,N;
/* инвариант цикла A */
do
<пока зона не отсортированных непуста> →
<уменьшить зону не отсортированных, не изменяя A>
od
{ R≡ массив M отсортирован }
end
Программа частично корректна, если
1) из I, преобразованного оператором
k,б,с := 1,N,N следует А,
2) A – инвариант цикла,
3) из А следует R по завершении цикла
Программа тотально корректна, если
при этом зона неотсортированных
уменьшается на каждом шаге цикла
бк1 с N

Разработка программы, корректной по построению
begin
{ [∀i: (1≤i≤N)] M[i] – неотсортированный }
к,б,с:=1,N,N;
{A ≡ инвариант цикла}
do
к ≤б →
if [ ] M[б] = белый → б:=б-1;
[ ] M[б] = красный → поменять местами (M[б], M[к]); к:=к+1;
[ ] M[б] = синий → поменять местами (M[б], M[с]); с, б:=с-1, б-1;
fi
od
{R≡массив M отсортирован}
end
Для верификации программы нужно доказать:
1. sp (S0, I) ⇒ A или I ⇒ wp(S0, A)
2. A&¬G⇒R, т.е. A&(к<б) ⇒ R
3 -5. sp( Si, A&G&Gi)⇒ A или A⇒wp(Si, A&G&Gi )
6. Завершение программы: нужно доказать,
что б-к уменьшается при каждом прохождении цикла
begin
{ I }
S0
{A}
do
G →
if [ ] G1 → S1;
[ ] G2 → S2;
[ ] G3 → S3
fi
od
{R}
end
бк1 с N
Охраняемые команды Дейкстры:
A ≡ [ ∀i: (1≤i<к) ] M[i] - красный
& [ ∀i: (б<i≤с) ] M[i] - белый
& [ ∀i: (с<i≤N) ] M[i] - синий
& [ ∀i: (к≤i≤б) ] M[i] - неотсортированный
& (к≥1) & (б≤с) & (с≤N)

Проектирование ПО на основе моделей
(Model Driven Development. MDD)
Модель
Верификация
Программа
требований
Имитационное
моделирование
Техническое
задание
Высокоуровневая
документация
Разработка
тестов
Бортовое ПО для Airbus А-340: более 70% кода сгенерировано
Абсурдно
ставить
проблему
доказательства
программы
после того, как
программа
написана
(Н.Н.Непейвода)
Разумно ли
СНАЧАЛА построить
самолет, а
ПОТОМ проводить
анализ, чтобы
увидеть, полетит ли
он?

Verified Software Initiative
 Tony Hoare, Jayadev Misra, Gary T. Leavens, and Natarajan Shankar
(2007)
 Предлагают международный амбициозный исследовательский
долговременный проект по разработке основ конструирования
error-free программных систем
 Попытка в течение следующих 15 лет:
 Разработать обстоятельную Теорию программирования,
покрывающую формализмы и методики, необходимые для построения
практических надежных программ (error-free software)
 Разработать программные инструменты для анализа ПО
индустриального масштаба
 Построить библиотеки надежных программных компонент, которые
могут быть использованы в реальных проектах

Заключение

Biting the Silver Bullet
 Frederic Brooks (1986 г., “No Silver Bullet”) - об иллюзиях и надеждах в
разработке ПО. Ни одна из предлагаемых в то время идей не является
“серебряной пулей”, которая спасет нас от ужасов, связанных с разработкой
больших комплексов ПО. Весьма пессимистический взгляд
David Harel, IEEE Computer, 1992
David Harel (1992): хотя единственного средства (“серебряной пули”)
нет, но интегральное использование новых идей может внести
существенный вклад в разработку сложных программных систем

Возрастающее использование формальных методов
для верификации ПО на ранних стадиях разработки
 Среди наиболее обещающих направлений:
 разработка более тонких формализмов спецификации требований
 объединение статического анализа кода и верификации
 композициональная разработка и верификация
 Model Driven Development: проверяемая модель – в центре разработки,
генерация кода из отлаженной и верифицированной модели
 синтез СУ непосредственно из спецификации (синтез супервизоров)
Д. Харел (1992):
“Текущая ситуация и перспективы значительных улучшений
показывают, что мы находимся на пороге новой, удивительной эры”
Сегодняшние успехи формальной верификации показывают:
“БУДУЩЕЕ НАЧИНАЕТСЯ СЕГОДНЯ”
Верификация достигла уровня зрелости, но требует интеллектуальных
усилий в ее применении и дальнейшем развитии

Спасибо за внимание

TMPA-2013 Conference: Verification of Parallel Programs – Current Stage and Perspectives

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (15)

Semelhante a TMPA-2013 Conference: Verification of Parallel Programs – Current Stage and Perspectives

Semelhante a TMPA-2013 Conference: Verification of Parallel Programs – Current Stage and Perspectives (20)

Mais de Iosif Itkin

Mais de Iosif Itkin (20)

TMPA-2013 Conference: Verification of Parallel Programs – Current Stage and Perspectives