Компьютерра - Компьютерра PDA N116 (18.06.2011-24.06.2011)
- Название:Компьютерра PDA N116 (18.06.2011-24.06.2011)
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Компьютерра - Компьютерра PDA N116 (18.06.2011-24.06.2011) краткое содержание
ОГЛАВЛЕНИЕ
Сергей Голубицкий: Голубятня: Айпадодицея
Василий Щепетнев: Василий Щепетнёв: По следам Ляпкина-Тяпкина
Киви Берд: Кивино гнездо: Обратная сторона битмонеты
Ваннах Михаил: Кафедра Ваннаха: Вернём бионику?
Олег Нечай: Путеводитель по новым мобильным процессорам
Евгений Лебеденко, Mobi.ru: Система строгого режима: Microsoft Singularity (часть 1)
Василий Щепетнев: Василий Щепетнёв: Мерзость запустения
Олег Нечай: Новые мобильные процессоры. Часть 2
Дмитрий Шабанов: Награда за красоту
Ваннах Михаил: Кафедра Ваннаха: Семьдесят лет и один день
Евгений Лебеденко, Mobi.ru: Система строгого режима: Microsoft Singularity (часть 2)
Олег Нечай: Наборы системной логики для процессоров Intel
Василий Щепетнев: Василий Щепетнёв: Обеднение урана
Олег Нечай: Системные платы для платформы Intel Sandy Bridge
Компьютерра PDA N116 (18.06.2011-24.06.2011) - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
Оставим в покое пользователя-любителя, что с него возьмёшь. Зачастую сама операционная система не ведает, что творят работающие процессы. Многозадачная архитектура современных систем, разработанная в начале семидесятых годов прошлого столетия, подразумевала продуманность каждой запускаемой программы и минимальное количество в ней критических ошибок, дотошно вылавливаемых на этапе программирования и отладки кода. И, конечно же, то, что работающие одновременно программы написаны в соответствии с высшими компьютерными заповедями - не убий своими действиями другой процесс, не укради чужие данные, не нарушай адресное пространство процесса-соседа... - те времена давно прошли. Нынешние программы крадут и убивают, пользуясь тем, что в основе современных систем продолжают лежать принципы "мир, дружба, жвачка".
Но что если изменить нынешнее положение дел, создав совершенно новую операционную систему, учитывающую "криминальные" реалии нынешних информационных технологий? Вы скажете, утопическая идея?
Между тем для её реализации существуют чётко определённые подходы, основанные на том, что любые действия любых работающих программ будут жёстко контролироваться, а их возможности будут ограничиваться только заложенными в программу легитимными и проверенными функциями.
Решить эту, казалось бы, нереальную задачу можно как минимум тремя способами.
Первый - прибегнуть к тотальной, дотошной и тщательнейшей проверке корректности работы всех компонентов системы с традиционной архитектурой и всех работающих в её рамках программ на предмет фатальных ошибок и кода, потенциально опасных действий с разделяемыми объектами и данными и прочих подозрительных и несанкционированных манипуляций. А также осуществить дальнейший запрет на какие-либо модификации проверенной системы и программ. Такая проверка обычно выполняется экспертно и требует много времени и немалых средств. На её выходе появляется система, которой можно доверять (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) файл.
Читать дальшеИнтервал:
Закладка: