Коллектив Авторов - Цифровой журнал «Компьютерра» № 74

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

В системах, подобных Singularity, предполагается тщательная верификация кода программы, которая будет в данный момент выполняться. Результат такой верификации — строгое математическое доказательство того, что этот код, именуемый проверенно безопасным (verifiably safe code), в ходе своего выполнения будет работать только с положенными ему объектами и не станет вносить никаких изменений в код и данные других процессов.

То есть, запуская любую программу, система предварительно удостоверяется в полной легитимности работы и, следовательно, полностью контролирует процесс её выполнения. Это и есть идея управляемого выполнения кода.

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

Но разве предварительная верификация кода не снижает производительность системы? Ведь такая проверка не менее затратна по времени и ресурсам, чем переключение процессов.

Ответ на этот вопрос кроется в прогрессе программных платформ управляемого выполнения кода. Основанные на типобезопасных языках, таких, например, как Java или C#, и высокопроизводительных runtime компиляторах, способных «на лету» генерировать оптимальный и дотошно проверенный код, на системах сборки мусора, корректно очищающих память после завершения работы программы, подобные платформы в последнее время сделали гигантский скачок в плане производительности. Теперь она соизмерима с выполнением обычного неуправляемого кода.

Процесс управляемого выполнения кода — основа архитектуры системы Singularity. Базируется он на спецификации Microsoft CLS ( Common Language Specification), поддержка которой открыта для многих из имеющихся и вновь разрабатываемых языков программирования и компиляторов для них. Согласно CLS, эти компиляторы не генерируют неуправляемый код, а создают некий промежуточный код на языке MSIL ( Microsoft Intermediate Language). Дополнительно с генерацией кода MISL они создают манифест — метаданные программы, в которых чётко описаны её типы, сведения о необходимых программе внешних объектах и правила взаимодействия с ними. Код MISL и манифест упаковываются в исполняемый PE (portable executable) файл.

Дальше происходит компиляция 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)

К оглавлению

Опубликовано23 июня 2011 года

Продолжение. Первую часть читайте здесь.

Singularity — микроядерная система. Весь код небольшого и тщательно проверенного на типобезопасность микроядра в большинстве сво`м написан на языке Sing# — подмножестве языка C#, специально разработанного для этой системы в Microsoft Research. Код ядра не верифицируется перед исполнением, поэтому он называется доверенным (trusted). Вообще-то в ядре есть небольшие фрагменты небезопасного кода, написанные на C++ и ассемблере, но они тщательно изолированы в уровне аппаратных абстракций HAL.

Ядро содержит типичный для микроядра набор менеджеров, управляющих памятью, переключением процессов, вводом-выводом, безопасностью. К доверенному коду относится и run-time среда — компиляторы в MSIL и машинный код.

Код всех запускаемых в Singularity прикладных программ, сервисов и драйверов является строго верифицируемым.

Любая запускаемая программа или сервис с точки зрения Singularity является SIP — Software Isolated Process (программно изолированный процесс). Благодаря выполненной проверке типобезопасности SIP не нужно держать в «клетке» ограниченного адресного пространства. Он сам гарантирует свою лояльность — то, что будет работать только со строго определёнными объектами и данными, не нарушая целостности системы и других программ. А как же быть с межпроцессным взаимодействием? Без него в многозадачной среде никуда. Для взаимодействия SIP-ов Singularity предлагает очень надёжный механизм каналов, по которым один SIP может передавать другому сообщения и данные. Каналы в Singularity высокоскоростные и неплохо заменяют небезопасный механизм разделения данных в традиционных системах. SIP может общаться и с микроядром через специальный бинарный интерфейс ABI (Application Binary interface), с помощью которого один SIP может контролируемо повлиять на состояние другого SIP.