Тема 1

М.: Бином, 2014
С.В. Назаров Операционные системы Практикум М.: КНОРУС, 2014
Олифер

В.Г., Олифер Н.А. Сетевые операционные системы СПб: Питер, 2013
Гордеев А. Операционные системы. Учебник для ВУЗов. СПб: Питер, 2012.
Таненбаум Э. Современные операционные системы. СПб: Питер, 2012.

англ. – СПб.: Питер, 2013.
Иртегов Д.Л. Введение в операционные системы.

СПб: Питер, 2010
Стахнов А.А.Linux - СПб: БХВ- Санкт-Петербург, 2012

ЭВМ
Физические устройства (контроллеры, шины, монитор и т. д.)
Микроархитектура (регистры ЦП,

АЛУ)

Утилиты

Компиляторы

Редакторы

Интерпретаторы команд

Прикладные программы

Конечный пользователь

Программист

Машинный язык

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

Разработчик ОС

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

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

типа ресурса:
планирование ресурса  то есть определение, какому процессу, когда

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

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

вводом-выводом.
Обеспечение безопасности

Операционных систем нет
Второй период (1955 г.–начало 60-х). Компьютеры на основе

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

полное отсутствие какого-либо ПО, программирование путем коммутации устройств.
Начало 50-х г.

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

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 ассемблер (микроядро – 1600 С и 800 ассемблер)
1991 г. – Linux (Линус Торвальдс).

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

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

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

ресурсами
3.1. Многозадачность:
однозадачные (MS DOS),
невытесняющая многозадачность (Windows 3.x, NewWare),
вытесняющая многозадачность (Windows NT, OS/2, Unix)

имеется (Windows NT, Unix)

3.3. Многопроцессорная обработка:
отсутствие, асимметричные ОС, симметричные ОС

4. По базовой технологии (Юникс-подобные или подобные Windows)
5. По типу лицензии (проприетарная или открытая)
6. Область использования и форма эксплуатации
пакетная обработка (OS/360)
разделение времени
реальное время (QNX)

виртуальной 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))

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

в привилегированный, а при возврате к приложению  переключение из

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

механизмы ядра
Менеджеры ресурсов
Интерфейс системных вызовов

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

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

отражается специфика аппаратной платформы компьютера. В идеале этот слой полностью

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

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

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

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

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

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

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

небольшая часть ОС, называемая микроядром
Микроядро защищено от остальных частей

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

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

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

Машинно-зависимые модули
Базовые механизмы ядра
Утилиты. Системные программы
Приложения пользователей
Средства аппаратной поддержки

ОС

Аппаратура

API

Сервер безопасности

ыыы

Файловая система

Драйвер устройств

Менеджер процессов

Менеджер виртуальной памяти

Интерфейс системы ввода-вывода

Утилиты ОС, приложения

РЕЖИМ ЯДРА

Пользовательский режим

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

ПОЛЬЗОВАТЕЛЯ
РЕЖИМ ЯДРА
Запрос
Ответ
Запрос
Ответ
Сервер
процессов

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

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

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

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

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

ОС
Приложение
t
t
t
t
Р Е Ж И М

Я Д Р А

Р Е Ж И М ПОЛЬЗОВАТЕЛЯ

Достоинства: единообразные интерфейсы, расширяемость, гибкость, переносимость, надежность, поддержка распределенных систем, поддержка объектно-ориентированных ОС.

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

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

р а т у р а
Модули
ОС
Пример: ранние версии ядра

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

затем связать их вместе в единый объектный файл с помощью

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

(НЯ) – крайне упрощённое и минимальное ядро, выполняет лишь одну

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

2. Микроядро (МЯ) предоставляет только элементарные функции управле-ния процессами и минимальный набор абстракций для работы с оборудованием. Бо́льшая часть работы осуществляется с помощью специальных пользователь-ских процессов, называемых сервисами. В микроядерной операционной системе можно, не прерывая ее работы, загружать и выгружать новые драйверы, файло-вые системы и т. д. Микроядерными являются ядра ОС Minix и GNU Hurd и ядро систем семейства BSD.

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

предоставляет широкий набор абстракций оборудования. Все части ядра работают в

одном адресном пространстве. МЯ требуют перекомпиляции при изменении состава оборудования. Компоненты операционной системы являются не самостоятельными модулями, а составны-ми частями одной программы. МЯ более производительно, чем микроядро, поскольку работает как один большой процесс. МЯ является большинство Unix-систем и Linux. Монолитность ядер усложняет отладку, понимание кода ядра, до-бавление новых функций и возможностей, удаление ненужного, унаследованно-го от предыдущих версий, кода. «Разбухание» кода монолитных ядер также по-вышает требования к объёму оперативной памяти.

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

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

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

переключая процессы по прерыванию или по истечении времени.
Уровень 1

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

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

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

операционным системам предъявляются не менее важные рыночные требования:
1. Расширяемость
2. Переносимость
3.

Надежность и отказоустойчивость
4. Совместимость
5. Производительность
6. Безопасность

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

целостность системы.

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

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

и от внешних ошибок, сбоев и отказов. Ее действия должны

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

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

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

это позволяет аппаратная платформа.
На производительность ОС влияет много факторов,

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

Производительность

несанкционированного доступа. Чтобы ОС обладала свойством безопасности, она должна как

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

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

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

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

настоящему времени стандарт POSIX рассматривается как семейство родственных стандартов: IEEE

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

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

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

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

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

известный стандарт критериев оценки пригодности компьютерных систем (Trusted Computer System

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

разработка. Этот уровень требует, чтобы защиту секретной и другой критичной

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

оценочных уровней (Evaluation Assurance Levels – EAL). Их также семь:

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

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

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

на уровне 4 стандарта Общих критериев и ниже, что говорит

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