Рекомендации NASA по написанию безопасных программ
Nov 30, 2010 · CommentsБезопасностьПрограмирование
Читаю местами увлекательный документ «NASA Software Safety Guidebook». Документ содержит рекомендации по написанию безопасных программ. Тех самых, которые в космос летают. Чуть менее чем всё из того, что там написано применимо и для обычного софта.
Хотя есть и космический экстрим, конечно. Например, идет речь о мультипрограммировании (N-Version Programming). Одна и та же функциональность реализуется разными способами. Если разные версии возвращают одинаковый результат, то всё в порядке. Если результаты не совпадают, то используется голосование, чтобы определить какой результат наиболее достоверный. Для защиты от одного сбоя нужно написать три разных реализации; от двух – пять.
Теперь интересное:
One major problem with N-Version programming is that it increases complexity, which has a direct relationship with the number of errors. In one NASA study of an experimental aircraft, all of the software problems found during testing were the result of the errors in the redundancy management system. The control software operated flawlessly!
Одна из главных проблем мультипрограммирования состоит в повышении сложности, что напрямую влияет на количество ошибок. Одно из исследований экспериментального самолета проведённое NASA показало, что все программные ошибки, найденные во время тестирования, были результатом ошибок в системе резервирования. Управляющее программное обеспечение работало безупречно!
И еще:
Another difficulty with N-Version programming is that achieving true independence is very difficult. Even if separate teams develop the software, studies have shown that the software is still often not truly independent.
Другая сложность мультипрограммирования состоит в трудности достижения настоящей независимости (версий). Даже если программное обеспечение разрабатывается разными командами, исследования показывают, что разные версии все равно не являются по-настоящему независимыми.
Секция про языки тоже забавна. Сначала речь идет о «безопасном подмножестве» языков. Из него исключаются все мало-мальски неоднозначные, сложные, спорные и просто неудачные языковые конструкции. Далее разбираются разные языки. Про Ada – не интересно. Язык специально создавался для подобных применений. Ассемблер принимается за необходимое зло. Про Си написано уже интереснее:
In many ways, C is a higher level assembly language. This gives it great flexibility, and opens a Pandora’s box of possible errors.
Во многом, Си – это ассемблер высокого уровня. Это даёт значительную гибкость и открывает ящик Пандоры с возможными ошибками.
Ну да. Что есть, то есть.
Restricting the C language to certain constructs would not be feasible because the resulting language would not have the necessary functionality.
Ограничение языка Си до определенного набора разрешенных конструкций не представляется возможным, так как получившийся язык не обладал бы нужной функциональностью.
Практически все конструкции языка придуманы, чтобы программист, в конце концов, прострелил себе ногу.
С++:
A standard “safe subset” of C++ does not presently exist.
Стандартное «безопасное подмножество» C++ на данный момент не существует.
… и вряд ли появится.
Don’t use the RTTI (Run-Time Type Information). It was added to support object oriented data bases. If you think it’s necessary in your program, look again at your design.
Не используйте RTTI. Эта функциональность была добавлена для поддержки объектно-ориентированных баз данных. Если вы думаете RTTI необходима вашей программе, пересмотрите свой дизайн.
+1. Но пассаж про ОО базы данных непонятен.
Про C# написали, что это интерпретируемый язык. Про NGEN они не в курсе. С другой стороны, ну зачем им сборщик мусора во встроенной железке?
Forth:
Forth has no “safety” features.
В Форте нет «безопасных» конструкций.
Просто и понятно. Ну и так далее. Там даже Visual Basic есть.
В приложении есть рекомендации для каждого языка. Попадаются волшебные:
Use comments to describe WHAT the procedure or section is meant to do. It is not always clear from the assembly code.
Используйте комментарии для описания того ЧТО процедура или секция должны делать. Это не всегда понятно из ассемблерного кода.
Черт, а я-то думал!
Рекомендую чтиво, в общем.