слайд. Виртуальные машины

Слайд.

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

Смарт-карты (англ. Smart Card) представляют собой пластиковые карты со встроенной микросхемой.

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

Слайд

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

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

 

Существует шесть различных структур ОС для смарт-карт:

• монолитные системы;

• многоуровневые системы;

• микроядра­;

• клиент-серверные системы;

• виртуальные машины;

• экзоядра.

Слайд

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

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

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

Эта инструкция переключает машину из пользовательского режима в режим ядра и передает управление операционной системе (шаг 6 на рис. 1). Затем операционная система извлекает параметры и определяет, какой системный вызов должен быть выполнен. После этого она перемещается по индексу в таблице, которая в строке k содержит указатель на про­цедуру, выполняющую системный вызов k (шаг 7 на рис. 1).

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

1. Основная программа, которая вызывает требуемую служебную процедуру.

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

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

 

Слайд

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

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

Слайд

Обобщением подхода, показанного на рис. 2, является организация операцион­ной системы в виде иерархии уровней, каждый из которых является надстройкой над нижележащим уровнем. Первой системой, построенной таким образом, была система THE, созданная в Голландии Э. Дейк- строй (Е. W. Dijkstra) и его студентами в 1968 году.

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

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

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

 

Слайд. Микроядра

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

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

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

Структура процесса МINIХ 3 показана на рис. 3. В ядре также размещен драйвер часов, потому что планировщик работает с ними в тесном взаимодействии. Все остальные драйверы устройств работают как отдельные пользовательские процессы.

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

 

Слайд.

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

Связь между клиентами и серверами часто организуется с помощью передачи со­общений. Чтобы воспользоваться службой, клиентский процесс составляет сообще­ние, в котором говорится, что именно ему нужно, и отправляет его соответствующей службе. Затем служба выполняет определенную работу и отправляет обратно ответ. Если клиент и сервер запущены на одной и той же машине, то можно провести опре­деленную оптимизацию, но концептуально здесь идет речь о передаче сообщений.

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

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

 

слайд. Виртуальные машины

Первые выпуски OS/360 были системами исключительно пакетной обработки. Но многие пользователи машин IBM/360 хотели получить возможность инте­рактивной работы с использованием терминала, поэтому различные группы раз­работчиков как в самой корпорации IBM, так и за ее пределами решили написать для этой машины системы с разделением времени. Позже была выпущена офици­альная система разделения времени — TSS/360, и когда она наконец-то дошла до потребителей, то была настолько громоздкой и медлительной, что под нее было переоборудовано всего лишь несколько вычислительных центров. В конечном счете от этого проекта отказались, после того как на него уже было потрачено 50 млн долларов (Graham, 1970).

 

Слайд. Экзоядра

Группа из научного центра IBM Scientific Center в Кембридже, Массачусетс, раз­работала систему, осно­ванную на следующем проницательном наблюдении: система с разделением времени обеспечивает 1) многозадачность и 2) расширенную машину с более удобным ин­терфейсом, чем у простого оборудования. Сущность VM/370 заключается в полном разделении этих двух функций.

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

Когда программа под управлением операционной системы CMS выполняет системный вызов, он перехватывается в системное прерывание операционной системы на своей собственной виртуальной машине, а не на VM/370, как это было бы при ее запуске на реальной, а не на виртуальной машине. Затем CMS вы­дает обычные команды ввода-вывода для чтения своего виртуального диска или другие команды, которые могут ей понадобиться для выполнения этого вызова. Эти команды ввода-вывода перехватываются VM/370, которая выполняет их в рам­ках моделирования реального оборудования. При полном разделении функций многозадачности и предоставления машины с расширенной архитектурой каждая из составляющих может быть намного проще, гибче и удобнее для обслуживания.