Основные принципы построения операционных систем

Работа добавлена:






Основные принципы построения операционных систем на http://mirrorref.ru

Лекция 13

Основные принципы построения

операционных систем

Среди множества принципов построения операционных систем перечислим несколько

наиболее важных: принцип модульности, принцип виртуализации, принципы

мобильности (переносимости) и совместимости, принцип открытости, принцип генерации

операционной системы из программных компонентов и некоторые другие.

Принцип модульности

Операционная система строится из множества программных модулей. Подмодулем

в общем случае понимают функционально законченный элемент системы,

выполненный в соответствии с принятыми межмодульными интерфейсами. По

своему определению модуль предполагает легкий способ его замены другим при

наличии заданных интерфейсов. Способы обособления составных частей операционной

системы в отдельные модули могут быть существенно разными, но чаще

всего разделение происходит именно по функциональному признаку. В значительной

степени разделение системы на модули определяется используемым методом

проектирования системы (снизу вверх или наоборот).

Особо важное значение при построении операционных систем имеютпривилегированные,

повторно входимые иреентерабельныемодули, ибо они позволяют более

эффективно использовать ресурсы вычислительной системы. Как мы уже знаем

свойство реентерабельности может быть достигнуто различными

способами, но чаще всего используются механизмы динамического выделения памяти

под переменные для нового вычислительного процесса (задачи). В некоторых

системах реентерабельность программы получают автоматически. Этого можно

достичь благодаря неизменяемости кодовых частей программ при исполнении, а

также автоматическому распределению регистров, автоматическому отделению

кодовых частей программ от данных и помещению последних в системную область

памяти, которая распределяется по запросам от выполняющихся задач. Естественно,

что для этого необходима соответствующая аппаратная поддержка. В других

случаях это достигается программистами за счет использования специальных системных

модулей.

Принцип модульности отражает технологические и эксплуатационные свойства

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

распространен одновременно на операционную систему, прикладные программы

и аппаратуру. Принцип модульности является одним из основных в UNIX-

системах.

Во всех операционных системах можно выделить некоторую часть наиболее важных

управляющих модулей, которые должны постоянно находиться в оперативной памяти для более скорой реакции системы на возникающие события и более эффективной организации вычислительных процессов. Эти модули вместе с некоторыми системными структурами данных, необходимыми для функционирования операционной системы, образуют так называемоеядро операционной системы .' Т а к как это действительно ее самая главная, центральная часть, основа системы. При формировании состава ядра требуется удовлетворить двум противоречивым требованиям. В состав ядра должны войти наиболее часто используемые системные модули. Количество модулей должно быть таким, чтобы объем памяти, занимаемый ядром, был не слишком большим. В его состав, как правило, входят модули по управлению системой прерываний, средства по переводу программ из состояния счета в состояние ожидания, готовности и обратно, средства по распределению основных ресурсов, таких как оперативная память и процессор.  Ранее

мы уже упоминали, что операционные системы могут бытьмикроядернымиимак-

роядерными (монолитными).В микроядерных операционных системах само ядро

очень компактно, а остальные модули вызываются из ядра как сервисные. При этом

сервисные модули могут размещаться и в оперативной памяти. В противоположность

микроядерным в макроядерных операционных системах главная супервизорная часть включает в себя большое количество модулей. Более подробно о микроядерных

и макроядерных операционных системах расскажем далее.

Помимо программных модулей, входящих в состав ядра и постоянно располагающихся

в оперативной памяти, может быть много других системных программных

модулей, которые получают название транзитных. Транзитные программные модули

загружаются в оперативную память только при необходимости и в случае

отсутствия свободного пространства могут быть замещены другими транзитными

модулями. В качестве синонима термина ≪транзитный≫ можно использовать термин

≪диск-резидентный≫.

Принцип особого режима работы

Ядро операционной системы и низкоуровневые драйверы, управляющие работой

каналов и устройств ввода-вывода, должны работать в специальном режиме работы

процессора. Это необходимо по нескольким причинам. Во-первых, введение

специального режима работы процессора, в котором должен исполняться только

код операционной системы, позволяет существенно повысить надежность выполнения

вычислений. Это касается выполнения как управляющих функций самой

операционной системы, так и прикладных задач пользователей. Категорически

нельзя допускать, чтобы какая-нибудь прикладная программа могла вмешиваться

(преднамеренно или в связи с появлением ошибок вычислений) в вычисления,

связанные с супервизорной частью операционной системы. Во-вторых, ряд функций

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

системы. К этим функциям мы, прежде всего, должны отнести функции,

связанные с управлением процессами ввода-вывода данных. Вспомните основные

принципы организации ввода-вывода :все операции ввода-вывода дан

ных объявляются привилегированными.Это легче всего сделать, если процессор

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

Поскольку любая программа требует операций ввода-вывода, прикладные программы

для выполнения этих (и некоторых других) операций обращаются к супервизорной

части операционной системы (модуль супервизора иногда называютсупервизором

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

Если запрос корректный и программа имеет право с ним обращаться, то запрос на

выполнение операции, как правило, передается соответствующему модулю операционной

системы. Множество запросов к операционной системе образует соответствующий

системныйинтерфейс прикладного программирования(Application Program Interface, API).

Принцип виртуализации

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

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

позволяет абстрагироваться от конкретных ресурсов, максимально обобщить их

свойства и работать с некоторой абстракцией, вобравшей в себя наиболее значимые

особенности. Этот принцип позволяет представить структуру системы в виде

определенного набора планировщиков процессов и распределителей ресурсов (мониторов) и использовать единую централизованную схему распределения ресурсов.

Следует заметить, что сама операционная система существенно изменяет наши

представления о компьютере. Она виртуализирует его, добавляя ему функциональности,

удобства управления, предоставляя средства организации параллельных

вычислений и т. д. Именно благодаря операционной системе мы воспринимаем

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

торые связаны с реально существующими в данной вычислительной системе. При

таком языковом представлении пользователя совершенно не интересует реальная

конфигурация вычислительной системы, способы эффективного использования

ее компонентов и подсистем. Он мыслит и работает с машиной в терминах используемого

им языка.

Чаще виртуальная машина, предоставляемая пользователю, воспроизводит архитектуру

реальной машины, но архитектурные элементы в таком представлении

выступают с новыми или улучшенными характеристиками, часто упрощающими

работу с системой. Характеристики могут быть произвольными, но чаще всего

пользователи желают иметь собственную ≪идеализированную≫ по архитектурным

характеристикам машину в следующем составе.

Q Единообразная по логике работы память (виртуальная) достаточного для выполнения

приложений объема. Организация работы с информацией в такой

памяти производится в терминах работы с сегментами данных на уровне выбранного

пользователем языка программирования.

•Произвольное количество процессоров (виртуальных), способных работать

параллельно и взаимодействовать во время работы. Способы управления процессорами,

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

•Произвольное количество внешних устройств (виртуальных), способных работать

с памятью виртуальной машины параллельно или последовательно, асинхронно

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

Степень приближения к ≪идеальной≫ виртуальной машине может быть большей

или меньшей в каждом конкретном случае. Чем больше виртуальная машина, реализуемая

средствами операционной системы на базе конкретной аппаратуры компьютера,

приближена к ≪идеальной≫ по характеристикам машине и, следовательно,

чем больше ее архитектурно-логические характеристики отличны от реально

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

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

принципа виртуализации может служить VDM-машина (Virtual DOS Machine)

—защищенная подсистема, предоставляющая полную среду типа MS DOS

и консоль для выполнения DOS-приложений. Как правило, параллельно может

выполняться практически произвольное число DOS-приложений, каждое в своей

VDM-машине. Такие VDM-машины имеются и в операционных системах Windows

1 компании Microsoft, в OS/2, в Linux.

Одним из аспектов общего принципа виртуализации является независимость программ

от внешних устройств, хотя иногда эту особенность выделяют особенно и называют

принципом. Она заключается в том, что связь программ с конкретными

устройствами производится не в процессе создания программы, а в период планирования

ее исполнения. В результате перекомпиляция при работе программы с новым

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

позволяет одинаково осуществлять операции управления внешними устройствами

независимо от их конкретных физических характеристик. Например, программе,

содержащей операции обработки последовательного набора данных, безразлично,

на каком носителе эти данные будут располагаться. Смена носителя и данных, размещаемых на них (при неизменности структурных характеристик данных), не привнесет каких-либо изменений в программу, если в системе реализован принцип

независимости программ от внешних устройств. Независимость программ от внешних

устройств реализуется в подавляющем большинстве операционных систем

общего применения. Ярким примером такого подхода являются операционные системы

с общим названием UNIX. Реализована такая независимость и в большинстве

современных операционных систем для персональных компьютеров.

Например, в системах Windows все аппаратные ресурсы полностью виртуализи-

рованы, и прямой доступ к ним со стороны прикладных (и системных обрабатывающих)

программ однозначно запрещен. В системах Windows NT/2000/XP даже

были введены понятияHAL(Hardware Abstraction Layer —уровень абстрагирования

аппаратуры) иHEL(Hardware Emulation Layer —уровень эмуляции аппаратуры),

и этот шаг очень помогает в реализации идей переносимости (мобильности)

операционной системы.

Принцип__мобильности

Мобильность, или переносимость, означает возможность и легкость переноса операционной системы на другую аппаратную платформу. Мобильная операционная

система обычно разрабатывается с помощью специального языка высокого уровня,

предназначенного для создания системного программного обеспечения. Такой

язык помимо поддержки высокоуровневых операторов, типов данных и модульных

конструкций должен позволять непосредственно использовать аппаратные

возможности и особенности процессора. Кроме этого, такой язык должен быть

широко распространенным и реализованным в виде систем программирования,

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

программирования должен быть достаточно распространенным и технологичным.

Одним из таких языков является язык С. В последние годы язык C++ также

стал использоваться для этих целей, поскольку идеи объектно-ориентированного

программирования оказались плодотворными не только для прикладного, но и для

системного программирования. Большинство современных операционных систем

были созданы именно как объектно-ориентированные.

Обеспечить переносимость операционной системы достаточно сложно. Дело в том

что архитектуры разных процессоров могут очень сильно различаться. У них может

быть разное количество рабочих регистров, причем часть регистров может

оказаться контекстно-зависимыми, как это имеет место в процессорах с архитектурой

ia32. Различия могут быть и в реализации адресации. Более того, для

операционной системы важной является не только архитектура центрального

процессора, но и архитектура компьютера в целом, ибо важнейшую роль играет

подсистема ввода-вывода, а она строится на дополнительных (по отношению к центральному процессору) аппаратных средствах. В таких условиях сделать эффективным

код операционной системы при условии создания его на языке типа C/C++

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

от аппаратных особенностей процессора, от типов поддерживаемых данных, способов

адресации, системы команд и других важнейших моментов, разрабатывается

на языке ассемблера. Очевидно, что модули, написанные на языке ассемблера,

при переносе операционной системы на процессор с иной архитектурой должны

быть написаны заново. Зато остальная (большая) часть кода операционной системы

может быть просто перекомпилирована под целевой процессор. Именно по этому

принципу в свое время была создана операционная система UNIX. Относительная

легкость переноса этой системы на другие компьютеры позволила сделать

ее одной из самых распространенных. Для обеспечения мобильности был даже

создан стандарт на интерфейс прикладного программирования, названный POSIX

(Portable Operating System Interface for Computer Environments —интерфейсприкладного

программирования для переносимых операционных систем).

К сожалению, на самом деле далеко не все операционные системы семейства UNIX

допускают относительно простую переносимость созданного для них программного

обеспечения, хотя сами они и поддерживают такую переносимость. Основная

причина тому — отход от единого стандарта API — POSIX. Очевидно, что платой

за универсальность, прежде всего, является потеря производительности при

выполнении операций ввода-вывода и вычислений, связанных с этими операциями.

Поэтому ряд разработчиков шли и до сих пор идут на отказ от принципа мобильности,

поскольку не всегда следование этому принципу экономически оправдано.

Если при разработке операционной системы сразу не следовать принципу мобильности, то в последующем очень трудно обеспечить перенос на другую платформу как самой операционной системы, так и программного обеспечения, созданного для нее. Например, компания IBM потратила долгие годы на перенос своей операционной системы OS/2, созданной для персональных компьютеров с процессора архитектуры ia32, на платформу PowerPC. Но даже если изначально в спецификации на операционную систему заложить требование легкой переносимости, то не значит, что его в последующем будет просто реализовать. Подтверждением тому является тот же проект OS/2-WindowsNT. Как известно, проект Windows NT обеспечивал работу этой операционной системы на процессорах с архитектуройia32,MIPS,Alpha (DEC),PowerPC. Однако в последующем трудности с реализацией этого принципа привели к тому, что нынешние версии операционных систем класса Windows NT (Windows 2000/XP) уже создаются только для процессоров с архитектурой ia32 и не поддерживают MIPS, Alpha и PowerPC.

Принцип совместимости

Одним из аспектов совместимости является способность операционной системы

выполнять программы, написанные для других систем или для более ранних версий

данной операционной системы, а также для другой аппаратной платформы.

Необходимо разделять вопросы двоичной совместимости и совместимости на уровне

исходных текстов приложений. Двоичная совместимость достигается в том случае,

когда можно взять исполняемую программу и запустить ее на выполнение на

другой операционной системе. Для этого необходимы: совместимость на уровне

команд процессора, совместимость на уровне системных вызовов и даже на уровне

библиотечных вызовов, если они являются динамически связываемыми.

Совместимость на уровне исходных текстов требует наличия соответствующего

транслятора в составе системного программного обеспечения, а также совместимости

на уровне библиотек и системных вызовов. При этом необходима перекомпиляция

имеющихся исходных текстов в новый выполняемый модуль.

Гораздо сложнее достичь двоичной совместимости между процессорами, основанными

на разных архитектурах. Для того чтобы один компьютер выполнял программы

другого (например, программу для персонального компьютера типа IBM

PC хочется выполнять на компьютере типа Мае от фирмы Apple), этот компьютер

должен работать с машинными командами, которые ему изначально непонятны.

Например, процессор типа PowerPC на Мас должен исполнять двоичный код, предназначенный для процессора i80x86. Процессор 80x86 имеет свои собственные дешифратор команд, регистры и внутреннюю архитектуру. Процессор PowerPC имеет

другую архитектуру, он не понимает непосредственно двоичный код 80x86, поэтому

должен выбрать каждую команду, декодировать ее, чтобы определить, для чего

она предназначена, а затем выполнить эквивалентную подпрограмму, написанную

для PowerPC. К тому же у PowerPC нет в точности таких же регистров, флагов и

внутреннего арифметико-логического устройства, как в 80x86, поэтому он должен

эмулировать все эти элементы с использованием своих регистров или памяти. И он

должен тщательно воспроизводить результаты каждой команды, что требует специально

написанных подпрограмм для PowerPC, гарантирующих, что состояние

эмулируемых регистров и флагов после выполнения каждой команды будет в точности

таким же, как и на реальном процессоре 80x86. Выходом в таких случаях

является использование так называемых прикладных сред, или эмуляторов. Учи-

тывая, что основную часть программы, как правило, составляютвызовы библио-

течных функций,прикладная среда имитирует библиотечные функции целиком

используя заранее написанную библиотеку функций аналогичного назначения а

остальные команды эмулирует каждую по отдельности.

Одним из средств обеспечения совместимости программных и пользовательских

интерфейсов является соответствие стандартам POSIX. Эти стандарты позволяют

создавать программы в стиле UNIX, которые впоследствии могут легко переноситься

из одной системы в другую.

Принцип генерируемоести

Согласно принципу генерируемости исходное представление центральной системной

управляющей части операционной системы (ее ядра и основных компонентов,

которые должны постоянно находиться в оперативной памяти) должно обеспечивать

возможность настройки, исходя из конкретной конфигурации конкретного

вычислительного комплекса и круга решаемых задач. Под генерацией операционной

системы понимается ее сборка (компоновка) из отдельных программных модулей.

В результате генерации получают скомпонованные двоичные коды операционной

системы и построенные системные таблицы, отражающие конкретную

конфигурацию компьютера. Эта процедура проводится редко перед достаточно

протяженным периодом эксплуатации операционной системы. Процесс генерации

осуществляется с помощью специальной программы-генератора и соответствующего

входного языка для этой программы, позволяющего описывать программные

возможности системы и конфигурацию машины. В результате генерации

получается полная версия операционной системы. Сгенерированная версия операционной

системы представляет собой совокупность системных наборов модулей

и данных.

Упомянутый раньше принцип модульности положительно проявляется при генерации

операционной системы. Он существенно упрощает ее настройку на требуемую

конфигурацию вычислительной системы. В наши дни при использовании

персональных компьютеров с принципом генерируемости операционной системы

можно столкнуться разве что при работе с Linux. В этой UNIX-системе имеется

возможность не только использовать какое-либо готовое ядро операционной системы,

но и самому сгенерировать (скомпилировать) такое ядро, которое будет оптимальным

для данного конкретного персонального компьютера и решаемых на

нем задач. Кроме генерации ядра в Linux имеется возможность указать и набор

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

модулями, непосредственно входящими в ядро системы, а часть — модулями, имеющими статус подгружаемых, транзитных.

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

В дальнейшем, при эксплуатации компьютера, можно изменить состав драйверов,

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

заменить для какого-нибудь устройства драйвер, отключить или добавить ту

или иную службу. Более того, для большей гибкости часто вводится механизм

поддержки нескольких конфигураций. Например, такие популярные системы,

к а к Windows 98 и Windows NT/2000/XP, предоставляют возможность создавать

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

имея всего одну операционную систему, за счет нескольких различающихся

конфигураций пользователь может получить несколько виртуальных систем,

различающихся составом установленного (работающего) оборудования, драйверов

и служб, и на выбор запускать одну из этих систем.

Принцип открытости

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

(модифицируемая, развиваемая) операционная система позволяет не только

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

было легко внести дополнения и изменения, если это потребуется, не нарушая

целостности системы. Прекрасные возможности для расширения предоставляет

подход к структурированию операционной системы по типу клиент-сервер с использованием микроядерной технологии. В соответствии с этим подходом операционная система строится как совокупность привилегированной управляющей

программы и набора непривилегированных служб — ≪серверов≫. Основная часть

операционной системы может оставаться неизменной, в то время как добавляются

новые службы или изменяются старые.

Этот принцип иногда трактуют как расширяемость системы.

К открытым операционным системам прежде всего следует отнести UNIX-системы

и, естественно, системы Linux.

Принцип обеспечения безопасности вычислений

Обеспечение безопасности при выполнении вычислений является желаемым свойством

для любой многопользовательской системы. Правила безопасности определяют

такие свойства, как защита ресурсов одного пользователя от других и установление

квот по ресурсам для предотвращения захвата одним пользователем всех

системных ресурсов (таких как память).

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

всего используется механизм учетных записей. Он предполагает проведениеаутен-

фикащипользователя при его регистрации на компьютере и последующуюавто-

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

доступ к нему со стороны любого пользователя становится невозможным. Делается

это для того, чтобы нельзя было получить базу данных с учетными записями. Если

получить файл с учетными записями, то посредством его анализа можно было бы узнать

пароль пользователя, по которому осуществляется аутентификация.

Во многих современных операционных системах гарантируется степень безопасности

данных, соответствующая уровню С2 в системе стандартов США. Основы

стандартов в области безопасности были заложены в документе ≪Критерии оценки

надежных компьютерных систем≫. Этот документ, изданный в США в 1983 году.

Национальным центром компьютерной безопасности (National Computer Security

Center), часто называют Оранжевой книгой.

В соответствии с требованиями Оранжевой книги безопасной считается система,

которая ≪посредством специальных механизмов защиты контролирует доступ к информации таким образом, что только имеющие соответствующие полномочия лица

или процессы, выполняющиеся от их имени, могут получить доступ на чтение, запись,

создание или удаление информации≫.

Иерархия уровней безопасности, приведенная в Оранжевой книге, помечает низший

уровень безопасности как D, а высший —как А.

В класс D попадают системы, оценка которых выявила их несоответствие требованиям

всех других классов.

Основными свойствами, характерными для систем класса С, являются наличие

подсистемы учета событий, связанных с безопасностью, и избирательный контроль

доступа. Класс (уровень) С делится на два подуровня: уровень С1 обеспечивает

защиту данных от ошибок пользователей, но не от действий злоумышленников.

На более строгом уровне С2 должны присутствовать:

  • средства секретного входа, обеспечивающие идентификацию пользователей

путем ввода уникального имени и пароля перед тем, как им будет разрешен

доступ к системе;

  • избирательный контроль доступа, требуемый на этом уровне, позволяет владельцу

ресурса определить, кто имеет доступ к ресурсу и что он может с ним

делать (владелец делает это путем предоставления разрешений доступа пользователю

или группе пользователей);

•средства аудита (auditing) обеспечивают обнаружение и запись важных событий, связанных с безопасностью, или любых попыток создать системные ресурсы, получить доступ к ним или удалить их; а защита памяти заключается в том, что память перед ее повторным использованием должна инициализироваться.

На этом уровне система не защищена от ошибок пользователя, но поведение его может быть проконтролировано по записям в журнале, оставленным средствами аудита.

Системы уровня В основаны на помеченных данных и распределении пользователей

по категориям, то есть реализуют мандатный контроль доступа. Каждому пользователю присваивается рейтинг защиты, и он может получать доступ к данным только в соответствии с этим рейтингом. Этот уровень в отличие от уровня С защищает систему от ошибочного поведения пользователя.

Уровень А является самым высоким уровнем безопасности, он требует в дополнение

ко всем требованиям уровня В выполнения формального математически обоснованного

доказательства соответствия системы требованиям безопасности.

Различные коммерческие структуры (например, банки) особо выделяют необходимость

учетной службы, аналогичной той, что предлагают государственные рекомендации

С2. Любая деятельность, связанная с безопасностью, может быть отслежена

и тем самым учтена. Это как раз то, что требует стандарт для систем класса С2 и что обычно нужно банкам. Однако коммерческие пользователи, как правило, не хотят расплачиваться производительностью за повышенный уровень безопасности. Уровень безопасности А занимает своими управляющими механизмами до 90 % процессорного времени, что, безусловно, в большинстве случаев неприемлемо.

Более безопасные системы не только снижают эффективность, но и существенно ограничивают число доступных прикладных пакетов, которые соответствующим

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

системы Solaris (версия UNIX) есть несколько тысяч приложений, а для

ее аналога уровня В —только около ста.

Микроядерные операционные системы

В микроядерных операционных системах мы можем выделить центральный компактный

модуль, относящийся к супервизорной части системы. Этот модуль имеет

очень небольшие размеры и выполняет относительно небольшое количество

управляющих функций, но позволяет передать управление на другие управляющие

модули, которые и выполнят затребованную функцию. Микроядро — это минимальная

главная (стержневая) часть операционной системы, служащая основой

модульных и переносимых расширений. Микроядро само является модулем

системного программного обеспечения, работающим в наиболее приоритетном

состоянии компьютера и поддерживающим связи с остальной частью операционной

системы, которая рассматривается как набор серверных приложений (служб).

В90-е годы XX века было весьма распространенным убеждение, что большинство

операционных систем следующих поколений будут строиться как микроядерные.

Однако практика показывает, что это не совсем так. Разработчики желают иметь

компактное микроядро, но при этом включить в него как можно больше функций,

исполняемых непосредственно этим программным модулем. Ибо выполнение за-

требованной функции другим модулем, вызываемым из микроядра, приводит

к дополнительным задержкам, и к дополнительным сложностям. Более того, имеется масса разных мнений по поводу того, как следует организовывать службы операционной

системы по отношению к микроядру; как проектировать драйверы устройств, чтобы добиться наибольшей эффективности, но сохранить функции драйверов максимально независимыми от аппаратуры; следует ли выполнять операции, не относящиеся к ядру, в пространстве ядра или в пространстве пользователя; стоит ли сохранять программы имеющихся подсистем (например, UNIX) или лучше отбросить все и начать с нуля.

Основная идея, заложенная в технологию микроядра заключается в том, чтобы

создать необходимую среду верхнего уровня иерархии, из которой можно легко

получить доступ ко всем функциональным возможностям уровня аппаратного

обеспечения. При этом микроядро является стартовой точкой для создания всех

остальных модулей системы. Все эти остальные модули, реализующие необходимые

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

При этом они получают статус обычного процесса или задачи. Можно сказать,

что микроядерная архитектура соответствует технологии клиент-сервер. Именно

эта технология позволяет в большей мере и с меньшими трудозатратами реализовать

перечисленные выше принципы проектирования операционных систем.

Важнейшая задача разработки микроядра заключается в выборе базовых примитивов,

которые должны находиться в микроядре для обеспечения необходимого и

достаточного сервиса. В микроядре содержится и исполняется минимальное количество

кода, необходимое для реализации основных системных вызовов. В число

этих вызовов входят передача сообщений и организация другого общения между

внешними по отношению к микроядру процессами, поддержка управления

прерываниями, а также ряд других весьма немногочисленных функций. Остальные

системные функции, характерные для ≪обычных≫ (не микроядерных) операционных

систем, обеспечиваются как модульные дополнения-процессы, взаимодействующие

главным образом между собой и осуществляю щие взаимодействие посредством передачи сообщений.

Для большинства микроядерных операционных систем основой для такой архитектуры

выступает технология микроядра Mach. Эта операционная система была

создана в университете Карнеги Меллон, и многие разработчики брали с нее пример.

Исполняемые микроядром функции ограничены в целях сокращения его размеров

и максимизации количества кода, работающего как прикладная программа.

Микроядро включает только те функции, которые требуются в целях определения

набора абстрактных сред обработки для прикладных программ и организации

совместной работы приложений. В результате микроядро обеспечивает только пять

различных типов сервисов:

•управление виртуальной памятью;

•поддержка заданий и потоков;

*взаимодействиемеждупроцессами (Inter-Process Communication, IPC);

* управление поддержкой ввода-вывода и прерываниями;

•сервисы хоста (host) и процессора.

Другие подсистемы и функции операционной системы, такие как файловые системы,

поддержка внешних устройств и традиционные программные интерфейсы,

оформляются как системные сервисы либо получают статус обычных обрабатывающих

задач. Эти программы работают как приложения на микроядре.

С применением концепции нескольких потоков выполнения на одно задание микроядро

создает прикладную среду, обеспечивающую использование мультипроцессоров;

при этом совсем не обязательно, чтобы машина была мультипроцессорной:

на однопроцессорной машине различные потоки просто выполняются в разное

время. Вся поддержка, требуемая для мультипроцессорных машин, сконцентрирована

в сравнительно малом и простом микроядре.

Благодаря своим небольшим размерам и способности поддерживать остальные

службы в виде обычных процессов, выполняющихся вместе с прикладными программами,

сами микроядра проще, чем ядра монолитных или модульных операционных

систем. С микроядром супервизорная часть операционной системы разбивается

на модульные части, которые могут быть сконфигурированы целым рядом

способов, позволяя строить большие системы добавлением частей к меньшим.

Например, каждый аппаратно-независимый нейтральный сервис логически отделен

и может быть сконфигурирован различными способами. Микроядра также

облегчают поддержку мультипроцессоров созданием стандартной программной

среды, которая может использовать несколько процессоров, если они есть, однако

если их нет, работает на одном. Специализированный код для мультипроцессоров

ограничен самим микроядром. Более того, сети из общающихся между собой микроядер

могут быть использованы для операционной системной поддержки возникающего

класса массивно параллельных машин.

В некоторых случаях использование микроядерного подхода на практике сталкивается

с определенными сложностями, что проявляется в некотором замедлении

скорости выполнения системных вызовов при передаче сообщений через микроядро

по сравнению с классическим подходом. С другой стороны, можно констатировать

и обратное. Поскольку микроядра малы и в значительной степени оптимизированы,

при соблюдении ряда условий они позволяют обеспечить характеристики

реального времени, требующиеся для управления устройсч вами и для высокоскоростных

коммуникаций. Наконец, хорошо структурированные микроядра обеспечивают

изолирующий слой для аппаратных различий, которые не маскируются

применением языков программирования высокого уровня. Таким образом, они

упрощают перенесение кода и увеличивают уровень его повторного использования.

Наиболее ярким представителем микроядерных операционных систем является

операционная система реального времени QNX. Микроядро QNX поддерживает

только планирование и диспетчеризацию процессов, взаимодействие процессов,

обработку прерываний и сетевые службы нижнего уровня. Это микроядро обеспечивает всего лишь пару десятков системных вызовов, но благодаря этому оно может быть целиком размещено во внутреннем кэше даже таких процессоров, как Intel 486. Как известно, разные версии этой операционной системы имели и разные объемы ядер — от 8 до 46 Кбайт. Чтобы построить минимальную систему QNX, требуется добавить к микроядру менеджер процессов, который создает процессы и управляет ими и памятью процессов.

Чтобы операционная система QNX была применима не только во встроенных

и бездисковых системах, нужно добавить файловую систему и менеджер устройств.

Эти менеджеры исполняются вне пространства ядра, так что ядро остается

небольшим.

Макроядерные операционные системы

Вмакроядерных,илимонолитных,операционных системах ядро, состоящее из множества

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

Очень плодотворным оказался подход, основанный на моделиклиент-сервер.Эта

модель предполагает наличие программного компонента — потребителя какого-

либо сервиса, иликлиента,и программного компонента — поставщика этого сервиса,

илисервера.Взаимодействие между клиентом и сервером стандартизируется,

так что сервер может обслуживать клиентов, реализованных различными способами

и, возможно, разными разработчиками. При этом главным требованием является

то, чтобы использовался единообразный интерфейс. Инициатором обмена

обычно является клиент, который посылает запрос на обслуживание серверу, находящемуся в состоянии ожидания запроса. Один и тот же программный компонент

может быть клиентом по отношению к одному виду услуг и сервером для

другого вида услуг. Модель клиент-сервер является скорее удобным концептуальным

средством ясного представления функций того или иного программного элемента

в той или иной ситуации, нежели технологией. Эта модель успешно применяется

не только при построении операционных систем, но и на всех уровнях

программного обеспечения, и имеет в некоторых случаях более узкий, специфический

смысл, сохраняя, естественно, при этом все свои общие черты. Микроядерные

операционные системы в полной мере используют модель клиент-сервер.

При поддержке монолитных операционных систем возникает ряд проблем, связанных

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

Однако следует заметить, что использование технологии клиент-сервер — это еще

не гарантия того, что операционная система станет микроядерной. В качестве подтверждения этому можно привести пример с операционными системами класса

Windows NT, которые построены на идеологии клиент-сервер, но которые тем не

менее трудно назвать микроядерными. Их ≪микроядро≫ имеет уже достаточно большой

размер, приставка ≪микро≫ здесь вызывает улыбку. Хотя по своей архитектуре

супервизорная часть этих систем без каких-либо условностей может быть отнесена

к системам, построенным на базе модели клиент-сервер. Причем для последних

версий операционных систем с общим названием NT (New Technology) еще более

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

клиент-сервер во взаимодействиях между модулями управляющей (супервизор-

ной) части. Для того чтобы согласиться с таким высказыванием, достаточно сравнить

операционную систему QNX и операционные системы Windows NT/2000/

ХР.

Основные принципы построения операционных систем на http://mirrorref.ru


Похожие рефераты, которые будут Вам интерестны.

1. Назначение и функции операционных систем. Принципы построения операционных, систем

2. Основные принципы построения современных систем химико-технологического мониторинга водно-химических режимов ТЭС

3. Принципы построения систем и сетей связи на основе эталонной модели

4. Принципы построения цифровых систем передачи различных уровней иерархии

5. Основные принципы построения ЭВМ

6. Экономическое содержание понятия налоговая система. Основные принципы построения налоговой системы

7. ОСНОВНЫЕ ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ СИСТЕМ

8. Определения Операционных систем

9. Основные принципы реформирования систем теплоснабжения

10. Системы анализа защищенности операционных систем

5 stars - based on 250 reviews 5