Верификация параллельных программ: современный этап и перспективы Юрий Глебович Карпов Санкт-Петербургский Политехнический университет [email protected]

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

Ю.Г.Карпов ТМРА 2013 Кострома 3 Пример параллельной программы: частично корректна, но тотально некорректна Параллельная программа разделения множеств (Э. Дейкстра) все наименьшие собираются в 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++ … Ю.Г.Карпов ТМРА 2013 Кострома 4 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 Тестированием найти ошибку невозможно!!

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

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

Ю.Г.Карпов ТМРА 2013 Кострома 7 СМИ о программных ошибках – каждый день  Апрель, 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" прервалась из-за ошибочной команды, посланной с Земли. АМС потеряна, где-то летает сама по себе

Ю.Г.Карпов ТМРА 2013 Кострома 8 Ошибки во встроенных программных системах автомобильной индустрии  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 Ю.Г.Карпов ТМРА 2013 Кострома 9

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

В NASA признали потерю Deep Impact  Последний успешный сеанс связи с Deep Impact состоялся 8 августа 2013, после чего контакт с зондом был потерян. По оценкам инженеров NASA, причиной обрыва связи стали ошибки в ПО, из-за чего зонд потерял ориентацию в пространстве  Deep Impact был запущен в январе 2005 года. Его основная миссия заключалась в исследовании кометы Темпеля; она успешно была завершена спустя полгода после запуска Ю.Г.Карпов ТМРА 2013 Кострома 11 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 как общий секрет и уверен, что установил связь с А

Ю.Г.Карпов ТМРА 2013 Кострома 13 Несет ли программист ответственность за потери человеческих жизней? Программирование является единственной областью инженерной деятельности, где разработчик не отвечает за качество своей работы Обычно ПО имеет 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 Ужасы из-за ошибок ПО - в Интернете:

Ю.Г.Карпов ТМРА 2013 Кострома 14 Конфуз с голосованием на выборах в Думу 4 декабря 2011  146.47%

Ю.Г.Карпов ТМРА 2013 Кострома 15 Конфуз с голосованием на “Эхе Москвы” 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 Параллельная композиция процессов:

Ю.Г.Карпов ТМРА 2013 Кострома 16 Свойства системы Система Верификация – метод повышения качества программ Процедура проверки Спецификация системы (формальная модель) Спецификация требований (на формальном языке)  Верификация - формальное доказательство того, что программная система удовлетворяет формально определенным требованиям Формально доказать можно только нечто формально определенн ое

Основные подходы к верификации программ  Алгебры процессов  Дедуктивная верификация - метод Флойда-Хоара Ю.Г.Карпов ТМРА 2013 Кострома 17

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} В начале программы - ограничения на исходные данные Ю.Г.Карпов ТМРА 2013 Кострома

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

Ю.Г.Карпов ТМРА 2013 Кострома 21 Оценка сложности доказательства ОС 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), требовали огромных усилий  программные инструменты неадекватны и трудны в использовании; верификация проводилась интерактивно  требовалась высокая квалификация для выполнения и спецификации, и анализа Ю.Г.Карпов ТМРА 2013 Кострома

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

Ю.Г.Карпов ТМРА 2013 Кострома 24 Model checking - прорыв в верификации ~ 20 лет назад – качественный прорыв в области верификации дискретных систем Разработан метод model checking, основанный на изящных формальных моделях

Ю.Г.Карпов ТМРА 2013 Кострома 25 Что такое Model checking?

Ю.Г.Карпов ТМРА 2013 Кострома 26 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

Ю.Г.Карпов ТМРА 2013 Кострома 27 Примеры формализации высказываний в 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) 

Ю.Г.Карпов ТМРА 2013 Кострома 28 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 Модель времени – последовательность целых (вчера, сегодня, завтра, …)

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

Ю.Г.Карпов ТМРА 2013 Кострома 30 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 – не выполняется на вычислении

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

Ю.Г.Карпов ТМРА 2013 Кострома 32 Темпоральная логика ветвящегося времени  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 Темпоральные логики: прорыв в формализации и понимании требований к поведению параллельных систем

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

Ю.Г.Карпов ТМРА 2013 Кострома 34 Спецификация свойств поведения дискретных схем σ0 ⊧ ¬p σ0 ⊧ F ¬q σ0 ⊧ G(p→q) σ0 ⊧ q U p σ0 ⊧ FG(¬pq) p,q p q q q … q p q q q q : :

Ю.Г.Карпов ТМРА 2013 Кострома 35 Структура Крипке синхронных схем 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 1 0 p=1, r=1, q=1 1 0 1 0 0 1 q=(pr) q p r p, r, q Структура Крипке:

Ю.Г.Карпов ТМРА 2013 Кострома 36 Структура Крипке как модель программы с конечным числом состояний Состояние программы – вектор значений ее переменных И метки (рс) Переходы – изменение операторами значений переменных программы Пусть атомарные утверждения, ИНТЕРЕСУЮЩИЕ НАС: а=х>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 х:=-2; у:=1; b a b b a b Если все переменные могут принимать конечное число значений, то граф конечен

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

Ю.Г.Карпов ТМРА 2013 Кострома 38 Model checking – проверка того, является ли данная структура Крипке моделью темпоральной формулы Логика высказываний F=(p  q )  r И Л <И, И, Л> <Л, И, Л> <Л, Л, И> Интерпретация <Л, Л, И> - модель формулы F Темпоральная логика Ф=AG[(p  E(q U r )] И Л Интерпрета ции PL – наборы значений переменных

К2 К1 К3 Интерпрета ции TL – структуры Крипке, в каждом состоянии которых свой набор значений переменных

Интерпретация К1 - модель формулы Ф Model checking – проверка того, является ли К моделью Ф

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

Ю.Г.Карпов ТМРА 2013 Кострома 40 Пример: отчет фирмы Rockwell Collins 2007г.

Ю.Г.Карпов ТМРА 2013 Кострома 41

Ю.Г.Карпов ТМРА 2013 Кострома 42

Ю.Г.Карпов ТМРА 2013 Кострома 43

Ю.Г.Карпов ТМРА 2013 Кострома 44

Ю.Г.Карпов ТМРА 2013 Кострома 45

Ю.Г.Карпов ТМРА 2013 Кострома 46

Ю.Г.Карпов ТМРА 2013 Кострома 47

Ю.Г.Карпов ТМРА 2013 Кострома 48

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

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

51 Атака на криптопротокол аутентификации Needham- Schreder Bob думает, что он говорит с Alice, а он говорит с Intruder! А В 1. А, NA PK(В) 2. NA , NB PK(А) 3. NB PK(В) 1:PK(I) 2:PK(B) 3:PK(A) 4:PK(A) 5:PK(I) 6:PK(B) Alice Bob Intruder Ю.Г.Карпов ТМРА 2013 Кострома

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

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

Ю.Г.Карпов ТМРА 2013 Кострома 54 “Оконный” алгоритм транзакционной памяти  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).

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

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

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

Ю.Г.Карпов ТМРА 2013 Кострома 58 Премия Тьюринга АСМ 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 даёт инженеру теорию, алгоритмы, элементы технологии, инструментарий с помощью которых он может проверять корректность нетривиальных параллельных и распределенных программ Ю.Г.Карпов ТМРА 2013 Кострома

Ю.Г.Карпов ТМРА 2013 Кострома 60 Материализация абстрактных понятий  Формализмы, на которых основан метод Model Checking:  темпоральные логики  линейное и ветвящееся время  структуры Крипке  недетерминированные автоматы Бюхи  бесконечные множества бесконечных цепочек (-языки)  синхронная и асинхронная композиция автоматов  неподвижные точки операторов на решетках предикатов ...  Все эти абстракции, которые и представить себе нельзя, привели к разработке мощной техники верификации, которая стала частью промышленной технологии разработки критического ПО и аппаратуры

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

Ю.Г.Карпов ТМРА 2013 Кострома 62 Перспективы верификации Нельзя надеяться, что программные системы из десятков миллионов строк кода могут быть полностью верифицированы прямо сейчас, непосредственным механическим применением существующих техник и технологий

Ю.Г.Карпов ТМРА 2013 Кострома 63 Композициональность: доказательство свойств всей системы на основе свойств отдельных компонент системы Одно из направлений: Rely - Guarantee Композициональность: метод определения свойств сложных структур через свойства составляющих их подструктур и правил их композиции

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

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

Ю.Г.Карпов Верификация. Model checking 66 Формализация инварианта A  [ i: (1i<к) ] M[i] - красный & [ i: (бб)  массив 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

Ю.Г.Карпов Верификация. Model checking 67 Разработка программы, корректной по построению 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: (б

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

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

Ю.Г.Карпов ТМРА 2013 Кострома 70 Заключение

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

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

Ю.Г.Карпов ТМРА 2013 Кострома 73 Спасибо за внимание