Первый - прибегнуть к тотальной, дотошной и тщательнейшей проверке корректности работы всех компонентов системы с традиционной архитектурой и всех работающих в её рамках программ на предмет фатальных ошибок и кода, потенциально опасных действий с разделяемыми объектами и данными и прочих подозрительных и несанкционированных манипуляций. А также осуществить дальнейший запрет на какие- либо модификации проверенной системы и программ. Такая проверка обычно выполняется экспертно и требует много времени и немалых средств. На её выходе появляется система, которой можно доверять (trusted OS). Конечно, с учётом того, что пользователь действительно доверяет квалификации экспертов. Принципы такой экспертизы и идею, заложенную в основу таких trusted OS, мы уже рассматривали.
Второй подход - разработка новой архитектуры операционной системы, основанной на возможности проверки корректности выполняющегося кода любой программы либо перед её запуском, либо прямо в ходе исполнения, и изоляции программы, после которой она сможет обращаться только к необходимым для её работы объектам.
Ну и наконец, можно использовать закладываемые в современные аппаратные платформы возможности виртуализации и доверенной загрузки кода. С их помощью можно создать гибридную систему, в которой новая безопасная и надёжная архитектура управляет виртуально изолированными небезопасными и ненадёжными традиционными архитектурными решениями.
Второй способ (новая архитектура ОС) реализуется в проекте Microsoft Singularity.
В недрах компании Microsoft, точнее - в её исследовательском центре Microsoft Research с 2006 года ведётся работа над архитектурой новой операционной системы. Проект Singularity не является 'убийцей' нынешней коммерчески успешной Windows, но может доказать, что система с программно изолированными процессами, основанная на идее управляемого выполнения кода, может быть безопаснее и надёжнее традиционных систем. Не потеряв при этом их производительности и расширяемости функций.
Идея, лежащая в основе Singularity, не нова. Разработчики программного обеспечения давно осознали невозможность полного контроля со стороны операционной системы за так называемым неуправляемым кодом. Кодом, созданным разнообразными компиляторами, способными допускать ошибки, неточности и двоякости трактования исходного текста программ. Кодом, которому операционная система передаёт управление в момент переключения задач и который за отведённый ему квант времени способен натворить много бед. Только потому, что система не знает, как он работает и с какими объектами взаимодействует.
Вообще-то для обуздания неуправляемого кода существует аппаратная архитектура, основанная на изоляции адресных пространств памяти каждого процесса, кольцах безопасности и продуманном механизме переключении задач. Но прямое её использование существенно снижает производительность системы, в которой трудится множество программ (аппаратное переключение контекста процесса требует сотни циклов работы процессора). Кроме того, все преимущества аппаратной поддержки защиты памяти сводятся на нет лояльностью к вопросам работы с разделяемыми объектами и данными - основой коммуникаций процессов в нынешних системах.
В системах, подобных Singularity, предполагается тщательная верификация кода программы, которая будет в данный момент выполняться. Результат такой верификации - строгое математическое доказательство того, что этот код, именуемый проверенно безопасным (verifiably safe code), в ходе своего выполнения будет работать только с положенными ему объектами и не станет вносить никаких изменений в код и данные других процессов.
То есть, запуская любую программу, система предварительно удостоверяется в полной легитимности работы и, следовательно, полностью контролирует процесс её выполнения. Это и есть идея управляемого выполнения кода.
В такой модели работы процессов для них не требуется аппаратно выделять изолированные адресные пространства памяти и следить за тем, чтобы их границы не были нарушены. Поскольку все будущие действия процесса верифицированы и строго доказана их безопасность для системы и других процессов, то можно сказать, что работа процессов изолирована друг от друга программным способом. Даже располагаясь в едином адресном пространстве памяти, процессы не смогут помешать работе друг друга.
Но разве предварительная верификация кода не снижает производительность системы? Ведь такая проверка не менее затратна по времени и ресурсам, чем переключение процессов.
Ответ на этот вопрос кроется в прогрессе программных платформ управляемого выполнения кода. Основанные на типобезопасных языках, таких, например, как Java или C#, и высокопроизводительных runtime компиляторах, способных 'на лету' генерировать оптимальный и дотошно проверенный код, на системах сборки мусора, корректно очищающих память после завершения работы программы, подобные платформы в последнее время сделали гигантский скачок в плане производительности. Теперь она соизмерима с выполнением обычного неуправляемого кода.
Процесс управляемого выполнения кода - основа архитектуры системы Singularity. Базируется он на спецификации Microsoft CLS (Common Language Specification), поддержка которой открыта для многих из имеющихся и вновь разрабатываемых языков программирования и компиляторов для них. Согласно CLS, эти компиляторы не генерируют неуправляемый код, а создают некий промежуточный код на языке MSIL (Microsoft Intermediate Language). Дополнительно с генерацией кода MISL они создают манифест - метаданные программы, в которых чётко описаны её типы, сведения о необходимых программе внешних объектах и правила взаимодействия с ними. Код MISL и манифест упаковываются в исполняемый PE (portable executable) файл.
Спецификация Microsoft CLS лежит в основе не только системы Singularity, но и среды разработки для традиционных систем .NET Framework
Дальше происходит компиляция MISL-кода в машинный код, специфичный для системы команд процессора, на котором запущена Singularity. Занимаются этим процессом или JIT-компилятор (just-in-time), генерирующий машинные команды для процессора 'на лету', или же программа-генератор NGen (Native Image Generator), создающая традиционный исполняемый образ. Важным является то, что в ходе работы и JIT-компилятора, и программы NGen создаваемый машинный код проверяется на типобезопасность. В случае доказательства того, что полученный код типобезопасен, он исполняется, в противном случае генерируется исключение. Программа не прошла проверку и требует внесения изменений в свой исходный текст.
Проверка на типобезопасность кода каждой программы возможна только тогда, когда чётко доказана корректность работы всех компонентов системы управляемого выполнения кода. В настоящее время в Singularity для процессоров Intel x86 код MSIL компилируется в машинные инструкции компилятором Bartok, разработанным в той же Microsoft Research. При этом команда Singularity исходит из предположения, что Bartok не содержит ошибок и гарантированно создаёт типобезопасный машинный код.
В будущем должен быть создан специальный типизированный ассемблер TAL (Typed Assembly Language), который потребует от каждой программы доказательств её типобезопасности.
Читайте далее:Система строгого режима: Microsoft Singularity (часть 2)
Василий Щепетнёв: Мерзость запустения
Автор: Василий Щепетнев
Воронежский парк отдыха и культуры в иные времена славился и сельскохозяйственной выставкой с показом быков, соболей и яйценоских кур, и шахматным павильоном, и прудом с цветущими лилиями
