Тема 1 Структура операционной системы. 2. 1. Ядро и вспомогательные модули ОС Наиболее общим подходом к структуризации операционной системы является разделение. - презентация

1 Тема 1 Структура операционной системы

2 2. 1. Ядро и вспомогательные модули ОС Наиболее общим подходом к структуризации операционной системы является разделение всех ее модулей на две группы: ядро модули ОС, выполняющие основные функции; ядро модули ОС, выполняющие основные функции; модули, выполняющие вспомогательные функции ОС. модули, выполняющие вспомогательные функции ОС.

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

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

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

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

7 2.2 Ядро и привилегированный режим Для надежного управления ходом выполнения приложений операционная система должна иметь по отношению к приложениям определенные привилегии. Для надежного управления ходом выполнения приложений операционная система должна иметь по отношению к приложениям определенные привилегии. Аппаратура компьютера должна поддерживать как минимум два режима работы пользовательский режим (user mode) и привилегированный режим, который также называют режимом ядра (kernel mode) или режимом супервизора (supervisor mode). Аппаратура компьютера должна поддерживать как минимум два режима работы пользовательский режим (user mode) и привилегированный режим, который также называют режимом ядра (kernel mode) или режимом супервизора (supervisor mode).

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

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

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

11 Трехслойная схема вычислительной системы Утилиты Ядро ОС Аппаратура 2.3 Многослойная структура ОС

12 Ядро может состоять из следующих слоев: Средства аппаратной поддержки Средства аппаратной поддержки Машинно-зависимые компоненты ядра Машинно-зависимые компоненты ядра Базовые механизмы ядра Базовые механизмы ядра Менеджеры ресурсов Менеджеры ресурсов Интерфейс системных вызовов Интерфейс системных вызовов

13 Средства аппаратной поддержки ОС До сих пор об операционной системе говорилось как о комплексе программ, но часть функций ОС может выполняться и аппаратными средствами. Типичный набор средств аппаратной поддержки ОС: средства поддержки привилегированного режима; средства поддержки привилегированного режима; средства трансляции адресов; средства трансляции адресов; средства переключения процессов; средства переключения процессов; система прерываний; система прерываний; системный таймер; системный таймер; средства защиты областей памяти. средства защиты областей памяти.

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

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

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

17 Интерфейс системных вызовов Этот слой является самым верхним слоем ядра и взаимодействует непосредственно с приложениями и системными утилитами, образуя прикладной программный интерфейс операционной системы. Этот слой является самым верхним слоем ядра и взаимодействует непосредственно с приложениями и системными утилитами, образуя прикладной программный интерфейс операционной системы. Функции API, обслуживающие системные вызовы, предоставляют доступ к ресурсам системы в удобной и компактной форме, без указания деталей их физического расположения. Функции API, обслуживающие системные вызовы, предоставляют доступ к ресурсам системы в удобной и компактной форме, без указания деталей их физического расположения.

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

19 Все остальные более высокоуровневые функции ядра оформляются в виде приложений, работающих в пользовательском режиме Все остальные более высокоуровневые функции ядра оформляются в виде приложений, работающих в пользовательском режиме Менеджеры ресурсов, являющиеся неотъемлемыми частями обычного ядра файловая система, подсистемы управления виртуальной памятью и процессами, менеджер безопасности, становятся «периферийными» модулями, работающими в пользовательском режиме и называются серверами ОС Менеджеры ресурсов, являющиеся неотъемлемыми частями обычного ядра файловая система, подсистемы управления виртуальной памятью и процессами, менеджер безопасности, становятся «периферийными» модулями, работающими в пользовательском режиме и называются серверами ОС

20

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

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

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

24 Монолитные системы

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

26 Однако даже такие монолитные системы могут быть немного структурированными

27 Обобщением предыдущего подхода является организация ОС как иерархии уровней. Уровни образуются группами функций операционной системы - файловая система, управление процессами и устройствами и т.п. Каждый уровень может взаимодействовать только со своим непосредственным соседом - выше- или нижележащим уровнем. Прикладные программы или модули самой операционной системы передают запросы вверх и вниз по этим уровням. Обобщением предыдущего подхода является организация ОС как иерархии уровней. Уровни образуются группами функций операционной системы - файловая система, управление процессами и устройствами и т.п. Каждый уровень может взаимодействовать только со своим непосредственным соседом - выше- или нижележащим уровнем. Прикладные программы или модули самой операционной системы передают запросы вверх и вниз по этим уровням. Первой системой, построенной таким образом была простая пакетная система THE, которую построил Дейкстра и его студенты в 1968 году. Первой системой, построенной таким образом была простая пакетная система THE, которую построил Дейкстра и его студенты в 1968 году.

28 Система имела 6 уровней. Система имела 6 уровней. Уровень 0 занимался распределением времени процессора, переключая процессы по прерыванию или по истечении времени. Уровень 0 занимался распределением времени процессора, переключая процессы по прерыванию или по истечении времени. Уровень 1 управлял памятью - распределял оперативную память и пространство на магнитном барабане для тех частей процессов (страниц), для которых не было места в ОП, то есть слой 1 выполнял функции виртуальной памяти. Уровень 1 управлял памятью - распределял оперативную память и пространство на магнитном барабане для тех частей процессов (страниц), для которых не было места в ОП, то есть слой 1 выполнял функции виртуальной памяти. Слой 2 управлял связью между консолью оператора и процессами. С помощью этого уровня каждый процесс имел свою собственную консоль оператора. Слой 2 управлял связью между консолью оператора и процессами. С помощью этого уровня каждый процесс имел свою собственную консоль оператора. Уровень 3 управлял устройствами ввода-вывода и буферизовал потоки информации к ним и от них. С помощью уровня 3 каждый процесс вместо того, чтобы работать с конкретными устройствами, с их разнообразными особенностями, обращался к абстрактным устройствам ввода-вывода, обладающим удобными для пользователя характеристиками. Уровень 3 управлял устройствами ввода-вывода и буферизовал потоки информации к ним и от них. С помощью уровня 3 каждый процесс вместо того, чтобы работать с конкретными устройствами, с их разнообразными особенностями, обращался к абстрактным устройствам ввода-вывода, обладающим удобными для пользователя характеристиками. На уровне 4 работали пользовательские программы, которым не надо было заботиться ни о процессах, ни о памяти, ни о консоли, ни об управлении устройствами ввода-вывода. На уровне 4 работали пользовательские программы, которым не надо было заботиться ни о процессах, ни о памяти, ни о консоли, ни об управлении устройствами ввода-вывода. Процесс системного оператора размещался на уровне 5. Процесс системного оператора размещался на уровне 5.

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

30 Современные концепции и технологии проектирования операционных систем Кроме функциональных требований к операционным системам предъявляются не менее важные рыночные требования: 1. Расширяемость 2. Переносимость 3. Надежность и отказоустойчивость 4. Совместимость 5. Производительность 6. Безопасность

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

32 Переносимость Если код ОС может быть сравнительно легко перенесен с процессора одного типа на процессор другого типа и с аппаратной платформы одного типа на аппаратную платформу другого типа, то такую ОС называют переносимой (portable) или мобильной. Для того чтобы обеспечить свойство мобильности ОС, разработчики должны следовать следующим правилам. Если код ОС может быть сравнительно легко перенесен с процессора одного типа на процессор другого типа и с аппаратной платформы одного типа на аппаратную платформу другого типа, то такую ОС называют переносимой (portable) или мобильной. Для того чтобы обеспечить свойство мобильности ОС, разработчики должны следовать следующим правилам. 1. Большая часть кода должна быть написана на языке, трансляторы которого имеются на всех машинах, куда предполагается переносить систему. Такими языками являются стандартизованные языки высокого уровня. Большинство переносимых ОС написано на языке С 2. Аппаратно-зависимый код должен быть надежно изолирован в нескольких модулях, а не быть распределен по всей системе. Изоляции подлежат все части ОС, которые отражают специфику процессора и аппаратной платформы в целом. Низкоуровневые компоненты ОС, имеющие доступ к процессорно-зависимым структурам данных и регистрам, должны быть оформлены в виде компактных модулей, которые могут быть заменены аналогичными модулями для других процессоров.

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

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

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

36 Безопасность ОС должна защищать данные и другие ресурсы вычислительной системы от несанкционированного доступа. Чтобы ОС обладала свойством безопасности, она должна как минимум иметь в своем составе средства аутентификации – определения легальности пользователей, авторизации предоставления легальным пользователям дифференцированных прав доступа к ресурсам, аудита – фиксации всех «подозрительных» для безопасности системы событий. Свойство безопасности особенно важно для сетевых ОС. В таких ОС к задаче контроля доступа добавляется задача защиты данных, передаваемых по сети. ОС должна защищать данные и другие ресурсы вычислительной системы от несанкционированного доступа. Чтобы ОС обладала свойством безопасности, она должна как минимум иметь в своем составе средства аутентификации – определения легальности пользователей, авторизации предоставления легальным пользователям дифференцированных прав доступа к ресурсам, аудита – фиксации всех «подозрительных» для безопасности системы событий. Свойство безопасности особенно важно для сетевых ОС. В таких ОС к задаче контроля доступа добавляется задача защиты данных, передаваемых по сети.

37 POSIX (Portable Operation Systems Interface) это стандарт, призванный обеспечить переносимость исходных текстов программ между ОС разных производителей. За основу стандартов POSIX были взяты ОС семейства UNIX. Первоначальный вариант стандарта POSIX появился в 1990 г. Разработкой стандартов POSIX занимаются рабочие группы Института инженеров по электротехнике и радиоэлектронике (Institute of Electrical and Electronics Engineers IEEE) США. Поэтому стандарты POSIX после утверждения имеют маркировку IEEE. Кроме того, существуют Международная организация по стандартизации (International Organization for Standardization ISO) и Международная электротехническая комиссия (International Electrotechnical Commission IEC). Эти организации могут утверждать стандарты IEEE в качестве международных. Стандарты совместимости и переносимости

38 Спецификации POSIX задают стандартный механизм взаимодействия приложения и ОС. К настоящему времени стандарт POSIX рассматривается как семейство родственных стандартов: IEEE Std 1003.n (где n – это номер). Стандарт ISO/IEC ( POSIX.1 или IEEE ) определяет интерфейс прикладного программирования (API) для операционных систем. Стандарт a (OS Definition) содержит базовые интерфейсы ОС – поддержку единственного процесса, поддержку многих процессов, управление заданиями, сигналами, группами пользователей, файловой системой, файловыми атрибутами, управление файловыми устройствами, блокировками файлов, устройствами ввода/вывода, устройствами специального назначения, системными базами данных, каналами, очередями FIFO, а также поддержку языка C.

39 Стандарт b (Realtime Extensions) содержит расширения реального времени – сигналы реального времени, планирование выполнения, таймеры, синхронный и асинхронный ввод/вывод, ввод/вывод с приоритетами, синхронизация файлов, блокировка памяти, разделяемая память, передача сообщений, семафоры. Чтобы стать POSIX-комплиантной, ОС должна реализовать не менее 32 уровней приоритетов. POSIX определяет три политики планирования обработки процессов: SCHED_FIFO – процессы обрабатываются в режиме FIFO и выполняются до завершения, SCHED_RR – round robin – каждому процессу выделяется квант времени, SCHED_OTHER – произвольная реализационно- зависимая политика, которая не переносима на другие платформы.

40 Стандарт c (Threads) касается функций поддержки многопоточной обработки внутри процесса – управление потоками, планирование с учетом приоритетов, мьютексы, приоритетное наследование в мьютексах, переменные состояния (condition variables). Стандарт ISO/IEC (POSIX.2 или IEEE ) определяет набор утилит и командных интерпретаторов. Стандарт ISO/IEC (POSIX.3 или IEEE ) определяет набор тестов, позволяющих определить POSIX- совместимость операционной системы.

41 Стандарты безопасности В связи со стандартами для ОС стоит отметить широко известный стандарт критериев оценки пригодности компьютерных систем (Trusted Computer System Evaluation Criteria – TCSEC). Этот стандарт разработан Министерством обороны США и известен также под названием "Оранжевая книга". В связи со стандартами для ОС стоит отметить широко известный стандарт критериев оценки пригодности компьютерных систем (Trusted Computer System Evaluation Criteria – TCSEC). Этот стандарт разработан Министерством обороны США и известен также под названием "Оранжевая книга". В ряде других стран были разработаны аналогичные критерии, на основе которых был создан международный стандарт Общие критерии оценки безопасности информационных технологий (далее просто – Общие критерии) (Common Criteria for IT Security Evaluation, ISO/IEC 15408). В ряде других стран были разработаны аналогичные критерии, на основе которых был создан международный стандарт Общие критерии оценки безопасности информационных технологий (далее просто – Общие критерии) (Common Criteria for IT Security Evaluation, ISO/IEC 15408).

42 В "Оранжевой книге" перечислены семь уровней защиты А1 – верифицированная разработка. Этот уровень требует, чтобы защиту секретной и другой критичной информации средствами управления безопасностью гарантировали методы формальной верификации. В3 – домены безопасности. Этот уровень предназначен для защиты систем от опытных программистов. В2 – структурированная защита. В систему с этим уровнем защиты нельзя допустить проникновение хакеров. В1 – мандатный контроль доступа. Защиту этого уровня, возможно, удастся преодолеть опытному хакеру, но никак не рядовым пользователям. С2 – дискреционный контроль доступа. Уровень С2 обеспечивает защиту процедур входа, позволяет производить контроль за событиями, имеющими отношение к безопасности, а также изолировать ресурсы. С1 – избирательная защита. Этот уровень дает пользователям возможность защитить личные данные или информацию о проекте, установив средства управления доступом. D – минимальная защита. Этот нижний уровень защиты оставлен для систем, которые проходили тестирование, но не смогли удовлетворить требованиям более высокого класса.

43 В Общих критериях введены похожие требования обеспечения безопасности в виде оценочных уровней (Evaluation Assurance Levels – EAL). Их также семь: EAL7 – самый высокий уровень предполагает формальную верификацию модели объекта оценки. Он применим к системам очень высокого риска. EAL6 определяется, как полуформально верифицированный и протестированный. На уровне EAL6 реализация должна быть представлена в структурированном виде, анализ соответствия распространяется на проект нижнего уровня, проводится строгий анализ покрытия, анализ и тестирование небезопасных состояний. EAL5 определяется, как полуформально спроектированный и протестированный. Он предусматривает создание полуформальной функциональной спецификации и проекта высокого уровня с демонстрацией соответствия между ними, формальной модели политики безопасности, стандартизованной модели жизненного цикла, а также проведение анализа скрытых каналов.

44 EAL4 определяется, как методически спроектированный, протестированный и пересмотренный. Он предполагает наличие автоматизации управления конфигурацией, полной спецификации интерфейсов, описательного проекта нижнего уровня, подмножества реализаций функций безопасности, неформальной модели политики безопасности, модели жизненного цикла, анализ валидации, независимый анализ уязвимостей. По всей вероятности, это самый высокий уровень, которого можно достичь на данном этапе развития технологии программирования с приемлемыми затратами. EAL3 определяется, как методически протестированный и проверенный. На уровне EAL3 осуществляется более полное, чем на уровне EAL2, тестирование покрытия функций безопасности, а также контроль среды разработки и управление конфигурацией объекта оценки. EAL2 определяется, как структурно протестированный. Он предусматривает создание описательного проекта верхнего уровня объекта оценки, описание процедур инсталляции и поставки, руководств администратора и пользователя, функциональное и независимое тестирование, оценку прочности функций безопасности, анализ уязвимостей разработчиками. EAL1 определяется, как функционально протестированный. Он обеспечивает анализ функций безопасности с использованием функциональной спецификации и спецификации интерфейсов, руководящей документации, а также независимое тестирование. На этом уровне угрозы не рассматриваются как серьезные.

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

46