Формально темой июньского номера журнала Computer (Computer, IEEE Computer Society, Vol. 40, No. 6, June 2007) являются многоядерные процессоры, однако в действительности этому посвящены только две статьи из шести.

Статья «Среда с открытыми кодами для программной системы Cell Broadband Engine» (An Open Source Environment for Cell Broadband Engine System Software) написана Микаелем Гшвиндом, Дэвидом Ербом, Сидом Мэннингом и Марком Наттером.

Создатели компьютеров редко внедряют новые архитектуры: существующие обладают такими преимуществами, как зрелость, привычность для программистов и доступность программного обеспечения. Новые архитектуры обычно появляются в ответ на тектонические сдвиги в технологиях и в состоянии рынка. К примеру, исходная архитектура IBM System/360 была первой, отвечавшей потребности массового производства. RISC-системы возникли в ответ на возникновение производства сверхбольших интегральных схем и появление однокристальных микропроцессоров. В связи с окончанием эпохи частотного масштабирования технологии КМОП архитекторы снова вынуждены прибегнуть к массовым технологическим изменениям на основе масштабирования за счет плотности. Возможным вариантом решения является Cell Broadband Engine (Cell BE) — первая реализация однокристалльного мультипроцессора со значительным числом программируемых ядер общего назначения, предназначенный для поддержки широкого набора рабочих нагрузок, включая интенсивную обработку мультимедийных и научных данных.

Разработка Cell была начата в 2000 году компаниями IBM, Sony и Toshiba для использования в игровой приставке PlayStation 3 и других средах интенсивной обработки данных. Целью проекта было достижение производительности, на порядок превосходящей производительность настольных компьютеров образца 2005 года. Для этого разработчикам требовалось оптимизировать производительность по отношению к контактной поверхности, мощности, объему и стоимости способом, невозможным при использовании предыдущих архитектур. Их стратегия заключалась в использовании параллелизма за счет наличия многочисленных ядер, поддерживающих устоявшиеся модели приложений, что должно было обеспечивать хорошие возможности программирования и поддерживать эффективность работы программистов.

Архитектура Cell Broadband Engine Architecture (CBEA) распределенного многоядерного однокристального микропроцессора пригодна для поддержки обработки больших массивов вещественных чисел при поддержке рабочих нагрузок интенсивных вычислениями и мультимедийных приложений. В первой реализации CBEA, мультипроцессоре Cell BE на одном кристалле имеются один 64-разрядный процессорный элемент Power, восемь процессоров-акселераторов, называемых синергическими процессорными элементами, высокоскоростной контроллер памяти, широкополосная шина для соединения элементов, а также высокоскоростные интерфейсы памяти и ввода/вывода.

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

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

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

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

Вторая статья подборки, написанная Нидхи Аггарвалом, Партасарати Ранганатаном, Норманном Юппи и Джеймсом Смитом, называется «Изоляция в массовых многоядерных процессорах» (Isolation in Commodity Multicore Processors).

Тенденции к масштабированию технологии приводят к тому, что однокристальные мультипроцессоры (chip multiprocessor, CMP) становятся доминирующей парадигмой компьютерной аппаратуры. Множественные ядра интегрируются в одном кристалле, образуя мультипроцессоры общего назначения. С системной точки зрения CMP обеспечивают более высокий уровень интеграции, обычно включая несколько обрабатывающих ядер, кэшей, контроллеров памяти и даже обработку ввода/вывода. Например, в процессоре Sun Niagara имеется восемь ядер, общий кэш второго уровня и интегрированные контроллеры памяти и интерфейсы ввода/вывода. В кристалле процессора IBM Power имеется контроллер памяти.

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

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

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

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

Фейсал Кеблави и Дик Салливан представили статью «Доводы в пользу гибких стандартов безопасности NIST» (The Case for Flexible NIST Security Standards).

Недавно Национальный институт стандартов и технологии США (National Institute of Standards and Technology, NIST) приступил к выпуску нового вида стандартов безопасности информационных систем. В соответствии с принятым в 2002 году Федеральным актом об управлении информационной безопасностью (Federal Information Security Management Act, FISMA) эти стандарты регулируют процессы информационной безопасности в федеральных гражданских организациях и требуют стандартного контроля безопасности во всех родственных информационных системах федерального уровня.

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

Следующая статья называется «Практический опыт автоматизированной трассируемости» (Best Practices for Automated Traceability). Ее авторы — Джейн Клеланд-Хаунг, Рафаэлла Сеттими, Эли Романова, Брайан Беренбах и Стивен Кларк.

Трассируемость (traceability) требований, определяемая как «возможность следовать жизненному циклу требования в прямом и обратном направлениях», обеспечивает важную поддержку разработчикам программного обеспечения при разработке и сопровождении программных систем. Трассируемость помогает определить, что исследователи детализировали требования до уровня низкоуровневых компонентов, встроили эти компоненты в исполняемую систему и эффективно их протестировали. Эта возможность также помогает аналитикам понять последствия предложенных изменений и убедиться в отсутствии постороннего кода.

В многочисленных стандартах трассируемость упоминается как рекомендуемое или формально требуемое свойство. Так, в стандарте IEEE 830-1998 (standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html) утверждается, что спецификация требований к программному обеспечению (software requirements specification, SRS) должна являться трассируемой. В этом стандарте SRS определяется как трассируемая, «если понятно происхождение каждого требования, и спецификация способствует указанию ссылок на каждое требование при будущей разработке документации или ее модернизации». Требуются обратная трассируемость от требований к «предыдущим стадиям разработки» и прямая трассируемость от требований ко «всем документам, порожденным на основе SRS». Кроме того, от организаций, производящих системы с особыми требованиями к безопасности, часто формально требуется демонстрация того, что для всех частей кода прослеживаются действующие требования. Законы, подобные американскому акту Сарбейнса-Оксли, требуют реализации в организациях процессов управления изменениями с явными границами трассируемости для любых частей программного продукта, которые потенциально влияют на финансовое благосостояние организаций.

К сожалению, во многих организациях не удается внедрить практику эффективной трассируемости либо из-за трудностей создания, использования и поддержки связей, либо по причине того заблуждения, что затраты на поддержку трассируемости требований не окупаются. Традиционно связи трассируемости физически сохраняются в электронных таблицах, текстовых файлах, базах данных, или для их хранения используются инструментальные средства управления требованиями (requirements management, RM), такие как DOORS компании Telelogic или IBM Rational RequisitePro. Такие связи деградируют в ходе выполнения проекта, поскольку из-за нехватки времени не обновляются участниками проектной группы. Эта проблема обостряется при использовании аутсорсинга, когда возникает дистанция между экспертами и разработчиками.

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

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

Ю-Чи Ценг, Ю-Чиун Ванг, Кай-Янг Ченг и Яо-Ю Хсиех представили статью «iMouse: интегрированная система мобильного контроля с беспроводными датчиками» (iMouse: An Integrated Mobile Surveillance and Wireless Sensor System).

Выдающиеся достижения в областях микросенсорных микроэлектромеханических систем (microsensing microelectromechanical system, MEMS) и технологий беспроводных коммуникаций способствуют развитию беспроводных сенсорных сетей (wireless sensor network, WSN), состоящих из многих сенсорных узлов, плотно размещенных в пространстве. Каждый из этих узлов может собирать информацию об окружающей среде, и все узлы вместе могут поддерживать произвольную многозвенную маршрутизацию. WSN обеспечивают недорогой и удобный способ мониторинга физических сред. Традиционные системы контроля обычно собирают большой объем видеозаписей, поступающих от настенных камер. Для анализа этих данных требуется большой объем вычислений и человеческого труда. Интеграция в эти системы сенсорных возможностей WSN может привести к сокращению накладных расходов, обеспечивая при этом более развитые, учитывающие контекст сервисы.

Описываемая в статье интегрированная система мобильного контроля с беспроводными датчиками (integrated mobile surveillance and wireless sensor system, iMouse) состоит из многочисленных статических беспроводных сенсоров и нескольких более мощных мобильных сенсоров. Система управляется событиями: только при возникновении события некоторый мобильный сенсор выделяется для фиксации образов этого события — в системе iMouse можно избежать записи образов при отсутствии событий. Более дорогие мобильные сенсоры приписываются к участкам событий, и от них не требуется покрытие всего отслеживаемого пространства, поэтому достаточно иметь лишь небольшое число таких сенсоров. Система является модульной и масштабируемой — при добавлении к мобильным сенсорам более развитых устройств могут усилиться возможности восприятия системы, но замены существующих статических сенсоров не требуется.

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

Последняя большая статья номера называется «Аутентификация на основе паролей: предотвращение атак на словари» (Password-Based Authentication: Preventing Dictionary Attacks). Ее написали Сайкат Чакрабарти и Мукеш Сингхал.

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

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

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

До встречи в следующем номере, Сергей Кузнецов, kuzloc@ispras.ru.