Система строгого режима: Microsoft Singularity (часть 1)
Евгений Лебеденко, Mobi.ru
Опубликовано 21 июня 2011 года
В большинстве своём современные информационные системы не очень надёжны в эксплуатации, и корень этой проблемы скрывается в самой их архитектуре. Да, мы научились повышать надёжность и безопасность за счет внесения работу систем избыточности, связанной с резервированием критически важных данных и установкой специального программного обеспечения, следящего за возможными угрозами информационной безопасности. Мы учимся сводить к минимуму проблемы, связанные с конфликтами в работе программ и компьютерного «железа». И тем не менее мы не застрахованы от СМС-баннеров, «зависания» системы и потери данных в результате внезапного её «падения». Дивясь ежедневному прогрессу в цифровом мире, мы подспудно ощущаем его несовершенство. И, глядя на громкий анонс новой версии операционной системы, не можем не предчувствовать: главные проблемы предшественницы в ней никуда не денутся.
История сегодняшних проблем отсылает нас к далёкому прошлому. Во времена, когда компьютеры были большими, оперативная память маленькой, а юзеров не было и в помине. Были учёные и инженеры, использующие компьютеры для решения важных для них задач. Были исследователи, старающиеся сделать решение этих задач более быстрым и эффективным. В общем, были профессионалы. Они в точности знали, какой код и данные располагаются в каждом байте памяти, могли контролировать процесс выполнения программы и старались отлавливать ошибки, ведущие к фатальным последствиям.
Сегодня же на смену им пришли простые смертные со своими скромными задачами. Нельзя сказать, что это плохо — просто для решения этих повседневных задач требуется фундамент покрепче. Такой, который избавил бы людей от проблем, справиться с которыми невозможно без «заглядывания под капот». Разработчики, идя навстречу этим желаниям потребителя, облегчают ему жизнь, усложняя при этом жизнь системе.
Драйверы устройств, работающие в пространстве памяти ядра и способные на самые непредсказуемые действия. Динамически подгружаемые библиотеки, код которых одни программы могут перезаписывать в ущерб работе других программ. Бесчисленные уязвимости, основанные на концепции обмена данными через совместно используемые объекты. Все эти механизмы прекрасно работали в ситуации, когда пользователь-профессионал держал работу системы под контролем. Сегодня же юзер, устанавливая новый плагин для браузера, даже не представляет, что за код в нём реализован. А между тем этот плагин будет трудиться в адресном пространстве браузера и без зазрения совести пользоваться всеми возможностями своей родительской программы.
Оставим в покое пользователя-любителя, что с него возьмёшь. Зачастую сама операционная система не ведает, что творят работающие процессы. Многозадачная архитектура современных систем, разработанная в начале семидесятых годов прошлого столетия, подразумевала продуманность каждой запускаемой программы и минимальное количество в ней критических ошибок, дотошно вылавливаемых на этапе программирования и отладки кода. И, конечно же, то, что работающие одновременно программы написаны в соответствии с высшими компьютерными заповедями — не убий своими действиями другой процесс, не укради чужие данные, не нарушай адресное пространство процесса-соседа... — те времена давно прошли. Нынешние программы крадут и убивают, пользуясь тем, что в основе современных систем продолжают лежать принципы «мир, дружба, жвачка».
Но что если изменить нынешнее положение дел, создав совершенно новую операционную систему, учитывающую «криминальные» реалии нынешних информационных технологий? Вы скажете, утопическая идея?
Между тем для её реализации существуют чётко определённые подходы, основанные на том, что любые действия любых работающих программ будут жёстко контролироваться, а их возможности будут ограничиваться только заложенными в программу легитимными и проверенными функциями.
Решить эту, казалось бы, нереальную задачу можно как минимум тремя способами.
Первый — прибегнуть к тотальной, дотошной и тщательнейшей проверке корректности работы всех компонентов системы с традиционной архитектурой и всех работающих в её рамках программ на предмет фатальных ошибок и кода, потенциально опасных действий с разделяемыми объектами и данными и прочих подозрительных и несанкционированных манипуляций. А также осуществить дальнейший запрет на какие-либо модификации проверенной системы и программ. Такая проверка обычно выполняется экспертно и требует много времени и немалых средств. На её выходе появляется система, которой можно доверять (trusted OS). Конечно, с учётом того, что пользователь действительно доверяет квалификации экспертов. Принципы такой экспертизы и идею, заложенную в основу таких trusted OS, мы уже рассматривали.
Второй подход — разработка новой архитектуры операционной системы, основанной на возможности проверки корректности выполняющегося кода любой программы либо перед её запуском, либо прямо в ходе исполнения, и изоляции программы, после которой она сможет обращаться только к необходимым для её работы объектам.
