Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Программа подсчета числа автомашин на мосту 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 Тестированием найти ошибку невозможно!!

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Ю.Г.Карпов Верификация 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 как общий секрет и уверен, что установил связь с А

Slide 13

Slide 13 text

Ю.Г.Карпов ТМРА 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 Ужасы из-за ошибок ПО - в Интернете:

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Ю.Г.Карпов ТМРА 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 Параллельная композиция процессов:

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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 Кострома

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Ю.Г.Карпов ТМРА 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 строк доказательства

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Ю.Г.Карпов ТМРА 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) 

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Ю.Г.Карпов ТМРА 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 : :

Slide 35

Slide 35 text

Ю.Г.Карпов ТМРА 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 Структура Крипке:

Slide 36

Slide 36 text

Ю.Г.Карпов ТМРА 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 Если все переменные могут принимать конечное число значений, то граф конечен

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

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

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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 Кострома

Slide 52

Slide 52 text

Ю.Г.Карпов 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 Кострома

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

Ю.Г.Карпов ТМРА 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).

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

Ю.Г.Карпов ТМРА 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 : “Это великий пример того, как технология, изменившая промышленность, родилась из чисто теоретических исследований”

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

Ю.Г.Карпов Верификация. 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

Slide 67

Slide 67 text

Ю.Г.Карпов Верификация. 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: (б

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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