Компьютерно-операционно-системное.

Для начала порекламирую неплохой блог с занятной и полезной информацией: блог Guastavo Duarte (англ.) А в нём статьи о начальной загрузке, адресной арифметике и уровнях защиты. Если данные вопросы неинтересны или непонятны, дальше можно и не читать. Собственно, не читать можно в любом случае. Как и наборот. А теперь, после введения, очередная небольшая порция ворчания. Которое состоит в том, что вся эта адресная арифметика и кольца защиты сейчас настолько привычны, что мы даже и не представляем, что может быть по другому. А вот раньше, говорю я постанывая, посвистывая и с хрустом распрямляя позвоночник, мы работали в системах "real mode" безо всякой защиты и такие программы писали, такие, этакие..., да такие же как и сейчас, только поменьше. И которые при любой ошибке вызывали перезагрузку, которая, однако надо отметить, была значительно быстрее теперешней! Довольно занятные системы были в домикрософтовсую и до-ibm-pc-шную эру реального режима. Например, были всякие занятные системы основанные на паскале и модуле. Последная была, как нетрудно догадаться, модульная, причём драйвер устройства - такой же модуль, как и программа пользователя, никакой разницы. Никакой разницы не было, kernel mode or user mode. Одно вызывало другое. Это была экзотика, мини-компьютеры. А большие компьютеры делались на той же, что и сейчас архитектуре, с двумя режимами, режимом ядра и режимом пользователя. Главное в такой архитектуре - защитить ядро от программы пользователя, и программы друг от друга. Традиционно есть процесс, как единица защиты. Процессы защищены друг от друга, ядро защищено от процессов, процесс можно убить, все ресурсы утилизировать без вреда для системы. Внутри же процесса - никаких защит, делай всё, что угодно. Это традиционная архитектура операционных систем. Для неё и делаются все эти адресные арифметики, кольца защиты, виртуальная память с таблицами страниц и прочее. И она, эта архитектура позволяет заражать программы вирусами, исполнять код в стеке, переполнять буфера, позволяет почтовым программам модифицировать системные файлы, ну и конечно, позволяет выполнять и все остальные полезные функции, за что мы её и любим. Естественно была попытка сделать и менее традиционную архитектуру. Где нельзя заражать и выполнять. Где почти ничего нельзя, кроме того, что можно. Где защита сидит в каждом указателе, в каждом массиве, в каждой функции. Аппаратно нельзя выйти за границы. Аппаратно нельзя сделать из числа указатель. И функцию нельзя вызвать если нет на неё указателя. Абсолютная защита. Естественно, всё было задумано в Советском Союзе, как нетрудно догадаться по приведённому описанию, и там же успешно где-то реализовывалось в течении многих лет, до тех пор, пока Горбачёв не произнёс своё знаменитое "разрешено всё, что не запрещено", чем подрубил концепцию на корню. Я очень уважаю разработчиков Эльбруса за эту архитектуру. Увы, в полноте своей она несколько утопична, почти как коммунизм. Обе требуют от человека того, что он дать не может. Коммунизм требует нечеловеческой сознательности, а Эльбрус - нечеловеческой предусмотрительности при программировании на нечеловеческих языках. Хотя второе интересно было бы попробовать. Не знаю, что там будет дальше с Эльбрусом. Идеолог, академик Бабаян теперь работает в Интеле, хотя фирма существует. Но бог с ней, с фирмой. Дело в том, что в подобной системе тоже нет уровней ядра и пользователя. Если функции защищены друг от друга, то драйвер - это просто функция, такая же, как и любая другая. И файловая система - обычный модуль, как и любой другой. И никакой трансляции адресов не надо, и уровней защиты не надо и много всего прочего. Фактически, сложность аппаратуры не выше, чем традиционной. Кстати, упомянутая фирма недавно сделала таки свой микропроцессор, и двоичный компилятор для него. Респект, если работает. Это вам не винду перекрашивать. Хотя я опять отвлёкся, не про него хотел рассказать. Одно время казалось, что это всё где-то далеко в фантастических северных странах, в далёком прошлом или далёком будущем, но услышанная фраза "software isolation" заставила поменять точку зрения. Фраза очевидна - заменить аппаратные границы программными. В эпоху виртуальных машин даже нетривиальная архитектура возможна. Но виртуальная машина - только один из нескольких подходов к "software isolation" и далеко не самый эффективный. Второй подход исповедуют разработчики проекта Midori в Microsoft (бывшая Singularity). Они предлагают оставить процессы как границы защиты и проверить программно двоичный код процесса на то, что он не выйдет за границы и ничего не сделает запрещённого. Тогда этот процесс можно запускать без аппаратной защиты. Я скептически отношусь к данному подходу. И доказать очень сложно и выгода невелика - только производительность, что в наше время грядущих 64-процессорных ядер не самая большая проблема. Третий подход основан на идее генерации кода. Допустим программа существует на некоем байт-коде, а система строит реальный двоичный код сама при запуске. Как в .NET или Java. В таком случае если исходный байт-код не позволяет чего-то сделать то и двоичный код этого не сделает. И его можно запускать без аппаратной защиты. Подобные системы могли бы работать почти как Эльбрус без его аппаратных заморочек. Причём большая часть ядра может сама быть написана на подобном языке. Неудобство данного подхода в невозможности запускать программы в двоичном коде, написанные на non-managed языках. Мне кажется, наиболее перспективный подход, особенно для встроенных систем. Сейчас есть несколько проектов, Java OS, например. Привет вам от Модулы. Здесь выгод может быть множество: более простая аппаратная часть, более простая структура операционной системы, защищённость на уровне процедур или классов. К сожалению, языки типы Java или С# не могут достичь идеальной защиты и избавить нас от вирусов и троянов. Их байт код недостаточно ограничен для этого. Но вообще, я думаю, что software isolation - интересное направление. Но вряд ли пройдёт в mainstream. Слишком далеко мы все ушли в другую сторону. Куда мы без привычной винды.