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

1. Тема 1

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

2. Основная литература

1. С.В. Назаров , А.И. Широков Современные
2.
3.
4.
5.
операционные системы М.: Бином, 2015
С.В. Назаров Операционные системы
Практикум М.: КНОРУС, 2015
Олифер В.Г., Олифер Н.А. Сетевые
операционные системы СПб: Питер, 2014
Гордеев А. Операционные системы. Учебник
для ВУЗов. СПб: Питер, 2012.
Таненбаум Э. Современные операционные
системы. СПб: Питер, 2012.

3. Дополнительная литература:

Соломон Д., М.Руссинович Внутреннее
устройство Microsoft Windows/ Пер. с англ. –
СПб.: Питер, 2014.
Иртегов Д.Л. Введение в операционные
системы. СПб: Питер, 2010
Стахнов А.А.Linux - СПб: БХВ- СанктПетербург, 2013

4. Операционная система (ОС) как посредник между уровнем пользователя и аппаратурой ЭВМ

Конечный пользователь
Программист
Прикладные программы
Утилиты
Компиляторы Редакторы Интерпретаторы
Разработчик
ОС
команд
Операционная система
Машинный язык
Микроархитектура (регистры ЦП, АЛУ)
Физические устройства (контроллеры, шины, монитор и т. д.)

5. Операционная система (ОС) – это программа, которая обеспечивает возможность рационального использования оборудования компьютера

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

6. Управление ресурсами включает решение следующих общих задач, не зависящих от типа ресурса:

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

7. Основные функции ОС

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

8. Краткая история эволюции вычислительных систем

Первый период (1945–1955 гг.). Ламповые
машины. Операционных систем нет
Второй период (1955 г.–начало 60-х). Компьютеры
на основе транзисторов. Пакетные операционные
системы
Третий период (начало 60-х – 1980 г.).
Компьютеры на основе интегральных микросхем.
Первые многозадачные ОС
Четвертый период (с 1980 г. по настоящее время).
Персональные компьютеры. Классические,
сетевые и распределенные системы

9.

1946 г. – ENIAC (Electronic Numerical Integrator and Computer) –
полное отсутствие какого-либо ПО, программирование
путем коммутации устройств.
Начало 50-х г. – появление алгоритмических языков и системного
ПО.
Усложнение процесса выполнения программ:
1. Загрузка нужного транслятора.
2. Запуск транслятора и получение программы в машинных кодах.
3. Связывание программы с библиотечными подпрограммами.
4. Запуск программы на выполнение.
5. Вывод результатов работы на печатающее или другое
устройство.
Для повышения эффективности использования ЭВМ вводятся
операторы,
затем разрабатываются управляющие программы – мониторы прообразы
операционных систем.
1952 г. – Первая ОС создана исследовательской
лабораторией фирмы General Motors для IBM-701.
1955 г. – ОС для IBM-704. Конец 50-х годов: язык управления
заданиями и пакетная обработка заданий.

10.

1963 г. – ОС MCP (Главная управляющая программа) для
компьютеров B5000 фирмы Burroughs:
мультипрограммирование, мультипроцессорная обработка,
виртуальная память, возможность отладки программ на
языке исходного уровня, сама ОС написана на языке
высокого уровня.
1963 г. – ОС CTSS (Compatible Time Sharing System –
совместимая система разделения времени для компьютера
IBM 7094 – Массачусетский технологический институт.
1963 г. – ОС MULTICS (Multiplexed Information and
Computing Service) – Массачусетский технологический
институт.
1974 г. – (UNICS) UNIX (Uniplexed Information and Computing
Service) для компьютера PDP-7, публикация статьи Ритчи
(С) и Томпсона.
1981 г. – PC (IBM), DOS (Seattle Computer Products) – MS
DOS (Б. Гейтс).
1983г. – Apple, Lisa с Apple, Lisa с GUI (Даг Энгельбарт –
Стэнфорд).
1985 г. – Windows, X Windows и Motif (для UNIX).
1987 г. – MINIX (Э. Таненбаум) – 11800 стр. С и 800

11.

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

12. Классификация операционных систем

1. Назначение (универсальные, специализированные –
управление производством, обучение)
2. Способ загрузки (загружаемые, постоянно
находящиеся в памяти)
3. Особенности алгоритмов управления ресурсами
3.1. Многозадачность:
однозадачные (MS DOS),
невытесняющая многозадачность (Windows 3.x,
NewWare),
вытесняющая многозадачность (Windows NT, OS/2,
Unix)

13.

3.2. Многопользовательский режим:
отсутствие (MS DOS, Windows 3.x),
имеется (Windows NT, Unix)
3.3. Многопроцессорная обработка:
отсутствие, асимметричные ОС, симметричные ОС
4. По базовой технологии (Юникс-подобные или
подобные Windows)
5. По типу лицензии (проприетарная или открытая)
6. Область использования и форма эксплуатации
пакетная обработка (OS/360)
разделение времени
реальное время (QNX)

14.

7. Аппаратная платформа
7.1. ОС для смарт-карт (с интерпретатором
виртуальной Java-машины)
7.2. Встроенные ОС (Palm OS, Windows CE –
Consumer Electronics)
7.3. ОС для ПК (Windows 9.x, Windows 2000, Linux,
Mac OS X)
7.4. ОС мини-ЭВМ (UNIX для PDP-7)
7.5. ОС мэйнфреймов (OS/390 – пакетная
обработка, разделение времени, обработка
транзакций)
7.6. Серверные операционные системы для ЛВС,
Интранет и Интернет (UNIX, AIX, Windows
2000/2002, Linux)
7.7. Кластерные операционные системы (Windows
2000 Cluster Server, Sun Cluster (Solaris))

15. 1. Ядро и вспомогательные модули ОС

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

16. Состав ядра

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

17.

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

18. Вспомогательные модули ОС обычно подразделяются на следующие группы:

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

19.

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

20. 2 Ядро и привилегированный режим

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

21.

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

22.

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

23.

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

24. Трехслойная схема вычислительной системы

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

25.

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

26. Средства аппаратной поддержки ОС

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

27. Машинно-зависимые компоненты ОС

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

28. Базовые механизмы ядра

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

29. Менеджеры ресурсов

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

30. Интерфейс системных вызовов

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

31. 2.4 Концепция микроядерной архитектуры

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

32.

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

33. Микроядерная архитектура ОС

Менеджер процессов
Базовые механизмы ядра
Драйвер устройств
Файловая система
Сервер безопасности
API
Приложения пользователей
Менеджер виртуальной памяти
Утилиты. Системные программы
РЕЖИМ ЯДРА
Интерфейс системы ввода-вывода
ы
ы
ы
Утилиты ОС, приложения
Пользовательский режим
Микроядерная архитектура ОС
Машинно-зависимые модули
МИКРОЯДРО
(режим ядра)
Средства аппаратной поддержки ОС
Средства
аппаратной
поддержки
Средства аппаратной
поддержки
ОС ОС
Аппаратура
Аппаратура
Аппаратура

34.

Приложение
Сервер
Файл-
памяти
Принт-
сервер
сервер
Сервер
Запрос
процессов
Ответ
Запрос
Ответ
РЕЖИМ ПОЛЬЗОВАТЕЛЯ
РЕЖИМ ЯДРА
МИКРОЯДРО
А П П А Р А Т У Р А

35. Механизм обращения к функциям ОС, оформленным в виде серверов

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

36.

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

37. Смена режимов при выполнении вызова функции микроядра

Системный
вызов
Р Е Ж И М
ПОЛЬЗОВАТЕЛЯ
СЕРВЕР ОС
Приложение
Приложение
МИКРОЯДРО
t
t
Р Е Ж И М
МИКРОЯДРО
t
Я Д Р А
t
Достоинства: единообразные интерфейсы, расширяемость,
гибкость, переносимость, надежность, поддержка распределенных
систем, поддержка объектно-ориентированных ОС.

38. Недостатки микроядерной архитектуры

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

39.

Монолитная архитектура операционной системы
От приложений
системный интерфейс
М
о
д
у
л
и
ОС
А п п а р а т у р а
Пример: ранние версии ядра UNIX, Novell NetWare. Каждая процедура
имеет хорошо определенный интерфейс в терминах параметров и
результатов и может любую другую для выполнения нужной работы.

40.

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

41.

Классификация ядер операционных систем
1. Наноядро (НЯ) – крайне упрощённое и минимальное ядро, выполняет лишь
одну задачу – обработку аппаратных прерываний, генерируемых устройствами
компьютера. После обработки посылает информацию о результатах обработки
вышележащему программному обеспечению. Концепция наноядра близка к концепции HAL. НЯ используются для виртуализации аппаратного обеспечения реальных компьютеров или для реализации механизма гипервизора.
2. Микроядро (МЯ) предоставляет только элементарные функции управления процессами и минимальный набор абстракций для работы с оборудованием.
Бо́льшая часть работы осуществляется с помощью специальных пользовательских процессов, называемых сервисами. В микроядерной операционной системе
можно, не прерывая ее работы, загружать и выгружать новые драйверы, файловые системы и т. д. Микроядерными являются ядра ОС Minix и GNU Hurd и ядро
систем семейства BSD.
3. Экзоядро (ЭЯ) – предоставляет лишь набор сервисов для взаимодействия
между приложениями, а также необходимый минимум функций, связанных с
защитой: выделение и высвобождение ресурсов, контроль прав доступа, и т. д.
ЭЯ не занимается предоставлением абстракций для физических ресурсов – эти
функции выносятся в библиотеку пользовательского уровня (так называемую
libOS). В отличие от микроядра ОС, базирующиеся на ЭЯ, обеспечивают большую эффективность за счет отсутствия необходимости в переключении между
процессами при каждом обращении к оборудованию.

42.

4. Монолитное ядро (МЯ) предоставляет широкий набор абстракций
оборудования. Все части ядра работают в одном адресном пространстве. МЯ
требуют перекомпиляции при изменении состава оборудования. Компоненты
операционной системы являются не самостоятельными модулями, а составными частями одной программы. МЯ более производительно, чем микроядро,
поскольку работает как один большой процесс. МЯ является большинство Unixсистем и Linux. Монолитность ядер усложняет отладку, понимание кода ядра, добавление новых функций и возможностей, удаление ненужного, унаследованного от предыдущих версий, кода. «Разбухание» кода монолитных ядер также повышает требования к объёму оперативной памяти.
5. Модульное ядро (Мод. Я) – современная, усовершенствованная
модификация архитектуры МЯ. В отличие от «классических» МЯ, модульные
ядра не требуют полной перекомпиляции ядра при изменении состава аппаратного обеспечения компьютера. Вместо этого они предоставляют тот или иной
механизм подгрузки модулей, поддерживающих то или иное аппаратное обеспечение (например, драйверов). Подгрузка модулей может быть как динамической,
так и статической (при перезагрузке ОС после переконфигурирования системы).
Мод. Я удобнее для разработки, чем традиционные монолитные ядра. Они предоставляют программный интерфейс (API) для связывания модулей с ядром,
для обеспечения динамической подгрузки и выгрузки модулей. Не все части ядра
могут быть сделаны модулями. Некоторые части ядра всегда обязаны присутствовать в оперативной памяти и должны быть жёстко «вшиты» в ядро.

43.

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

44.

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

45.

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

46. Современные концепции и технологии проектирования операционных систем

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

47. Расширяемость

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

48. Переносимость

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

49. Надежность и отказоустойчивость.

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

50. Совместимость

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

51.

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

52. Безопасность

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

53. Стандарты совместимости и переносимости

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 в качестве
международных.

54.

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

55.

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

56.

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

57. Стандарты безопасности

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

58. В "Оранжевой книге" перечислены семь уровней защиты

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

59. В Общих критериях введены похожие требования обеспечения безопасности в виде оценочных уровней (Evaluation Assurance Levels –

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

60.

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

61.

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