Темой майского номера являются будущие операционные системы и парадигмы программирования («Future Operating Systems and Programming Paradigms»). Собственно этой теме посвящены только две большие статьи. Они кажутся мне очень интересными, и свой обзор я начну именно с них.

Эдвард Ли (Edward A. Lee, eal@eecs.berkeley.edu, University of California, Berkeley) представил статью «Проблемы использования потоков управления» («The Problem with Threads»).

Параллельное программирование является трудным, хотя многие технологи предсказывают, что ответом на завершение действия закона Мура явится возрастающее использование параллельных архитектур: многоядерных процессоров, или мультипроцессоров на кристалле (chip multiprocessor, CMP). Если стремиться к непрерывному наращиванию производительности, необходимо обеспечить возможность использования этого параллелизма в программах.

Одним из возможных технических решений является автоматическое распараллеливание последовательных программ. Однако многие исследователи сходятся в том, что методы автоматического распараллеливания исчерпали свои возможности и пригодны для использования только незначительных аппаратных параллельных средств. Следовательно, более параллельными должны стать сами программы.

Решению проблемы может помочь более ясное понимание того, почему параллельное программирование является трудным. Физический мир является в высшей степени параллельным, и наша способность к выживанию зависит от способности воспринимать одновременно происходящее физические явления. Однако эта способность не распространяется на параллельные программы, поскольку абстракции, на которых основывается параллельное программирование, даже отдаленно не напоминают параллельность физического мира. Мы настолько завязли в этих вычислительных абстракциях, что забыли о том, что они не является непреложными. Трудности параллельного программирования являются следствием использования этих абстракций, и если мы от них освободимся, проблема станет разрешимой.

В практике программирования общего назначения доминирует один подход к параллельному программированию – потоки управления (thread), или последовательные процессы с совместной памятью. Они составляют ключевую модель параллельности, поддерживаемую современными компьютерами, языками программирования и операционными системами. Многие используемые сегодня параллельные архитектуры общего назначения, например, симметричные мультипроцессоры, являются непосредственной аппаратной реализацией абстракции потоков управления.

В некоторых приложениях потоки управления можно использовать очень эффективно, например, в так называемых явно (embarrassingly) параллельных приложениях, в которых, по существу, порождается несколько независимых процессов (например, PVM gmake или Web-серверы). Независимость этих процессов несколько облегчает программирование, и абстракция отображается скорее в понятие процесса, а не потока управления. Совместное использование памяти в таких приложениях основывается на абстракциях базы данных, а параллельность управляется механизмом транзакций. Однако клиентские приложения не так просты.

Потоки управления не являются единственной возможностью для параллельного программирования. В научных приложениях, в которых параллельное программирование обуславливается требованиями производительности, доминируют языковые расширения распараллеливания под управлением данных и библиотеки передачи сообщений (PVM, MPI, и OpenMP). Компьютерные архитектуры, ориентированные на научные приложения, часто существенно отличаются от архитектур общего назначения. Например, в них обычно поддерживаются вектора и потоки. Однако даже в этой области написание параллельных программ остается утомительным делом. Несмотря на наличие гораздо лучших языков параллелизма под управлением данных, доминируют языки C и Fortran.

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

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

При программировании встроенных систем также часто используются модели распараллеливания, отличные от потоков управления. Программируемые архитектуры DSP (Digital Signal Processing, цифровая обработка сигналов) часто являются VLIW-машинами (Very Large Instruction Word, очень длинное командное слово). В видео-сигнальных процессорах часто комбинируются WLIW- и потоковая обработка. В сетевых процессорах обеспечивается явная аппаратная поддержка потоковых данных. Однако, несмотря на существенные инновации, на практике программные модели для этих областей остаются примитивными. Разработчики пишут низкоуровневый ассемблерный код, в котором используются конкретные аппаратные возможности, комбинируя этот код с кодом на языке C там, где эффективность не является критичной.

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

Однако основной проблемой параллельного программирования с использованием потоков данных является недетерминизм результирующей системы. В качестве характерного примера приводится ситуация, возникшая в системе Ptolemy II, которая разрабатывалась с 2000 г. в группе автора статьи (ptolemy.eecs.berkeley.edu). Система представляет собой среду поддержки параллельных моделей вычислений. Система разрабатывалась с использование потоков управления Java с синхронизацией на основе мониторов. Было выполнено тщательное проектирование и тестирование. Система использовалась многими исследователями, и до 2004 г. несколько лет в ней не наблюдались какие-либо ошибки. Однако в 2004 г. в системе возник синхронизационный тупик. Автор приходит к заключению, что с помощью тестирования никогда не удастся обнаружить все проблемы в нетривиальном многопотоковом коде.

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

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

Несмотря на наличие альтернатив, в области параллельного программирования продолжают доминировать потоки управления. Принятию альтернативных подходов препятствует, прежде всего, то, что само понятие программирования и базовые абстракции вычислений произрастают из последовательной парадигмы, которой придерживается большинство языков программирования. Синтаксически потоки управления поддерживаются либо за счет незначительных расширений этих языков (как в случае Java), либо за счет всего лишь внешней библиотеки. С точки зрения семантики такие расширения полностью подрывают детерминизм этих языков.

К сожалению, похоже, что на программистов больше влияет синтаксис, а не семантика. Укоренившимся альтернативам потоков управления (например, MPI и OpenMP) присуще то же свойство. Они не привносят в языки синтаксические изменения. Альтернативы, заменяющие традиционные языки (такие как Erlang и Ada) не прижились и, вероятно, не приживутся. Даже языки с незначительными синтаксическими изменениями (например, Split-C и Cilk) остаются известными лишь для посвященных.

Ситуация понятна: не следует стараться заменить установившиеся языки. Нужно основываться на них. Однако недостаточно использования только библиотек. Библиотеки не обеспечивают должной структурированности, навязывания паттернов и возможностей композиции. Правильный ответ состоит в использовании языков взаимодействий (coordination language), называемых также языками компоновками (composition language), которые обладают новым синтаксисом. Однако этот синтаксис служит целям, ортогональным целям установившихся языков программирования. В то время, как параллельные языки общего назначения (например, Erlang или Ada) должны включать синтаксические конструкции для выражения традиционных операций, таких как арифметические выражения, язык взаимодействий не обязан обеспечивать возможность спецификации чего-либо отличного от взаимодействий. Возможно, со временем удастся создать масштабируемый и эффективный визуальный язык, подобно тому, как некоторые части языка UML удалось использовать для объектно-ориентированного программирования. Или же можно представить масштабируемый текстуальный синтаксис, пригодный для спецификации таких же структур.

Языки взаимодействий существуют уже долгое время. Им тоже не удалось укорениться. Одной из причин является то, что они не обеспечивали однородности. Превалирующей мнением в среде исследователей языков программирования является то, что любой достойный язык программирования должен быть языком общего назначения. Как минимум, он должен быть настолько выразительным, чтобы для него можно было сделать компилятор. Однако лед быт разбит разработкой языка UML, который запросто комбинируется с C++ и Java. Программисты начали признавать совместное использование нескольких языков, особенно если эти разъединенные языки обеспечивают взаимно дополняющие возможности.

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

Статью «Можем ли мы сделать операционные системы надежными и безопасными?» («Can We Make Operating Systems Reliable and Secure?») написали Эндрю Таненбаум, Джоррит Хердер и Херберт Бос (Andrew S. Tanenbaum, ast@cs.vu.nl, Jorrit N. Herder, jnherder@cs.vu.nl, Herbert Bos, bos@cs.vu.nl, Vrije Universiteit, Amsterdam).

В современных операционных системах имеются две характеристики, делающие их ненадежными и небезопасными: они огромны и обладают очень плохой изоляцией сбоев. По оценкам авторов, ядро Linux содержит около 15000 ошибок, а Windows XP – больше 30000 ошибок. При этом около 70% кода операционных систем занимает код драйверов устройств, в которых ошибки встречаются в 3-7 раз чаще, чем в обычном коде. Невозможно найти и исправить все ошибки, а при исправлении ошибок часто привносятся новые ошибки.

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

Исследователи прилагают усилия к созданию более надежных операционных систем. Авторы статьи рассматривают четыре подхода, используемые исследователями для придания будущим операционным системам более высокого уровня надежности и безопасности. Наиболее консервативным является подход проекта Nooks, направленного на повышение надежности существующих операционных систем (таких как Windows и Linux). В Nooks поддерживается монолитная структура ядра, но ядро защищается от содержащих ошибки драйверов устройств путем обертывания каждого драйвера уровнем защитного программного обеспечения. Оболочка драйвера тщательно отслеживает все взаимодействия между драйвером и ядром. Целями проекта Nooks являются защита ядра от сбоев драйверов, автоматическое восстановление после отказа драйвера и достижение всего этого путем небольших изменений в существующих драйверах и ядре. Первая реализация была выполнена для Linux, но идеи применимы и к другим унаследованным операционным системам.

Хотя эксперименты показали, что Nooks может перехватить 99% фатальных ошибок драйверов и 55% прочих ошибок, система не является совершенной. В драйверах могут выполняться привилегированные команды, которым в них выполняться не полагается; в них может производиться запись в неверные порты; в них могут возникать бесконечные циклы. Группе Nooks пришлось вручную написать большое число оболочек драйверов, и в них самих могут содержаться ошибки. Тем не менее, этот проект является потенциально полезным шагом к повышению надежности унаследованных операционных систем.

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

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

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

Поверх уровня драйверов устройств располагается уровень серверов. Файловый сервер является небольшой программой, которая принимает запросы от пользовательских процессов по обработке Posix-совместимых вызовов, относящихся к файлам, и выполняет их. На этом уровне находится и менеджер процессов, который поддерживает управление процессами и памятью и выполняет Posix-совместимые системные вызовы (fork, exec и brk). Сервер реинкарнации является родительским процессом всех других серверов и всех драйверов. Если драйвер или сервер аварийно или по собственной инициативе завершается, или не отвечает на периодические запросы отклика, то сервер реинкарнации принудительно завершает его, если это требуется, и перезапускает из копии на диске или в основной памяти. В число других серверов входит сервер сети, поддерживающий весь стек TCP/IP; простой сервер имен, используемый всеми остальными серверами; и информационный сервер, способствующий отладке.

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

Межпроцессные взаимодействия (IPC) в MINIX 3 поддерживаются на основе передачи сообщений фиксированной длины с использованием принципа рандеву: система копирует сообщение напрямую от отправителя к получателю, когда оба они к этому готовы. Кроме того, поддерживается механизм асинхронного уведомления о событиях. События, о которых оказалось невозможно уведомить процесс, фиксируются в битовой шкале в таблице процессов. С системой передачи сообщений интегрирована обработка прерываний.

Надежность Minix 3 происходит из разных источников. Во-первых, размер кода, выполняемого в ядре, составляет около 4000 строк, и общее число ошибок – всего около 24. Небольшой размер ядра позволяет верифицировать его код вручную или на основе формальных методов. Особенности IPC позволяют избежать потребности управления буферами в ядре. Кроме того, для каждого процесса ограничены доступные примитивы IPC, включая адреса назначения и события, о которых происходит уведомление. Все структуры ядра являются статическими. Эти свойства значительно упрощают код и устраняют ошибки в ядре, связанные с переполнением буферов, «утечку памяти» (memory leak), несвоевременные прерывания и т.д.

В течение десятилетий мультисерверные архитектуры на основе микроядра критиковались за недостаточную эффективность. Однако различные проекты показали, что при модульной разработке можно достичь приемлемой производительности. Несмотря на то, что система Minix 3 не оптимизировалась для достижения высокой производительности, она работает достаточно быстро. Вынос с ядра драйверов привел к снижению производительности на 10%, и система собирается, включая ядро, общие драйверы и все серверы (112 компиляций и 11 редактирований связей) менее чем за 6 секунд на процессоре Athlon с 2,2 Ггц. Тот факт, что мультисерверная архитектура смогла обеспечить высоконадежную Unix-подобную среду за счет небольшого снижения производительности, показывает практичность этого подхода. Minix 3 для Pentium свободно распространяется под лицензией Беркли на сайте www.minix3.org.

Наиболее радикальный подход предложен в Microsoft Research. Система, называемая Singularity, пишется почти целиком на новом типизированном языке Sing#. Этот язык основан на C#, но дополнен примитивами передачи сообщений, семантика которых определяется формальными, письменными контрактами. Поскольку безопасность языка строго ограничивает поведение системы и процессов, все процессы выполняются в едином виртуальном адресном пространстве. Эта схема обеспечивает и безопасность, и эффективность. Кроме того, схема Singularity является гибкой, поскольку каждый процесс является замкнутым объектом и потому обладает собственным кодом, структурами данных, распределением памяти, подсистемой времени выполнения, библиотеками и сборщиком мусора. Устройство управления памятью используется только для отображения страниц, а не для образования отдельной защищенной области для каждого процесса. Ключевым принципом организации Singularity является запрещение динамических расширений процессов. В частности, не допускаются загружаемые драйверы и подключаемые модули браузеров. Такие расширения должны запускаться, как отдельные процессы.

Операционная система Singularity состоит из процесса микроядра и набора пользовательских процессов, обычно исполняемых в общем виртуальном адресном пространстве. Микроядро управляет доступом к аппаратуре, выделяет и освобождает память, создает, ликвидирует и планирует потоки управления, управляет синхронизацией потоков управления с помощью мьютексов, управляет межпроцессной синхронизацией с использованием каналов и управляет вводом-выводом. Каждый драйвер устройства выполняется в отдельном процессе.

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

В Singularity поддерживается совместно используемая процессами «куча» объектов, но в каждый момент времени каждый объект из кучи принадлежит только одному процессу. Однако владение объектом может быть передано другому процессу через канал. Например, когда драйвер диска считывает блок, он помещает этот блок в кучу. Потом система передает дескриптор (handle) этого блока процессу, запросившему данные, поддерживая принцип единственного владельца, но позволяя передавать данные без копирования.

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

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

Прошу прощения за столь долгий пересказ этих двух тематических статей. Мне они показались настолько интересными, что я не смог пожертвовать какими-либо их разделами. Теперь перейдем к остальным статьям майского номера. Статья «Спецификации интероперабельности Web-сервисов» («Web Services Interoperability Specifications») написана Хамидом Мотарахи Незхадом, Буалемом Бенаталлахом, Фабио Касати и Фаруком Тумани (Hamid R. Motahari Nezhad, hamidm@cse.unsw.edu.au, Boualem Benatallah, boualem@cse.unsw.edu.au, University of New South Wales, Fabio Casati, fabio.casati@hp.com, Hewlett-Packard Laboratories, Farouk Toumani, ftoumani@isima.fr, LIMOS-ISIMA, France).

Web-сервисы становятся предпочтительной технологией для реализации сервис-ориентированных архитектур (service-oriented architectures, SOA). Web-сервисы упрощают интероперабельность и, тем самым, интеграцию приложений. Они обеспечивают средства для обертывания существующих приложений, чтобы обеспечить разработчикам доступ к ним на основе стандартных языков и протоколов.

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

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

Статья «Обеспечение масштабируемости в системах реального времени» («Achieving Scalability in Real-Time Systems») написана Джорджио Буттаццо (Giorgio Buttazzo, giorgio.buttazzo@sssup.it, Scuola Superiore Sant’Anna, Pisa, Italy).

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

Эта взаимосвязь может использоваться в высокоуровневой стратегии в зависимости от потребностей исполняемого приложения. Например, система может снизить производительность для удлинения срока действия батарей или повысить производительность за счет увеличения энергопотребления. Однако при наличии временных и ресурсных ограничений производительность систем реального времени не всегда повышается при возрастании скорости процессора. Аналогично, при снижении скорости процессора качество предоставляемых услуг не всегда снижается ожидаемым образом.

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

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

Последняя большая статья майского номера, представленная (Andrew Rae, Invensys Rail Systems Australia, Andrew.J.Rae@wrsa.com.au, Colin Fidge, Queensland University of Technology, c.fidge@qut.edu.au, Luke Wildman, University of Queensland, luke@itee.uq.edu.au) называется «Анализ неисправностей коммуникационных устройств, критичных для безопасности» («Fault Evaluation for Security-Critical Communications Devices»).

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

Например, устройство разграничения доменов, допускающее потоки управляющей информации между сетями с разными уровнями безопасности, может включать десятки компонентов, сбои которых могут влиять на безопасность информации. К числу устройств разграничения доменов относятся диоды данных (data diode), допускающие потоки данных только в одном направлении; мультикомпьютерные коммутаторы, дающие возможность совместного использования периферийных устройств из разных доменов безопасности; контекстные фильтры, ограничивающие информационные потоки; и криптографические устройства, позволяющие передавать секретную информацию в небезопасных сетях.

Международные стандарты, такие как Common Criteria for Information Technology Security Evaluation, обеспечивают инфраструктуру и инструментальные средства анализа безопасности, но предоставляют недостаточное техническое руководство для высококачественного анализа. Полезны и традиционные методы анализа схемотехники, но их оказывается недостаточно для проведения анализа безопасности.

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

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

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