Защита системы 1 страница

Защита системы

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

Механизм защиты должен:

- различать авторизованное и не авторизованное использование;

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

- обеспечить средства реализации.

Сетевое обеспечение

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

- увеличить скорость вычислений;

- увеличить объем доступной информации;

- повысить надежность.

Командный интерфейс системы

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

- создание и управление процессов;

- управление вводом/выводом;

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

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

- доступ к файловой системе;

- защиту;

- поддержку работы сети.

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

- интерпретатор управляющих карт;

- процессор команд консолей;

- shell ( в Unix).

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

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

- выполнение программ - способность системы загружать программу в память и выполнять ее;

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

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

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

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

6. Монолитная архитектура

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

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

Заметим, что монолитную архитектуру имели самые первые поколения операционных систем.

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

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

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

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

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

Требования к архитектуре операционной системы

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

Проблема расширяемости операционной системы

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

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

Действительно, операционная система обычно живет довольно долго, например UNIX существует уже более 30 лет, Windows NT – более 10 лет. За время жизни операционной системы неизбежно появляется новое периферийное оборудование, поддержка которого не закладывалась в систему при ее проектировании. Тем не менее, для успешного существования на рынке, операционная система должна быстро реагировать на появление нового оборудования и обеспечивать его поддержку. Примером может служить появление и широкое распространение накопителей на компакт-дисках или Flash-памяти.

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

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

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

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

Проблема переносимости операционной системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Микроядерная архитектура

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

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

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

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

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

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

Достоинства:

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

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

Надежность

Поддержка распределенности

Недостатки:

Снижение производительности

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

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

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

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

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

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

8. Понятия вычислительного процесса и ресурса

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

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

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

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

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

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

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

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

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

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

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

он свободен и в системе нет запросов от задач более высокого приоритета к этому же ресурсу;

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

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

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

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

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

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

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

9. Прерывания

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

(по лекциям) По отношенияю к корпусу МП прерывания подразделяются на:

внешние :

аппаратные (маскируемые) - поступают через контролер прерываний немаскируемые - поступают на вход NMI. У МП 2 входа для получения сигналов

внутренние :

программные - программа сама вызывает обработчик прерываний - вызов в коде исключения (исключительные ситуации процессора) - в реальном режиме 2 исключения: деление на ноль и пошаговый (?) режим (флаг трассировки и выполнение прерываени после команды)

Организация прерываний: векторный способ, опрашиваемый способ.

Схема аппаратных прерываний

Номер прерывания в реальном режиме - номер ячейки в таблице прерываний. Сам вектор - адрес точки входа в обработчик прерываний. В реальном ержиме таблица прерываний - в младших адресах ОП, представляет собой последовательность адресов в виде сегмент-смещение, 4 байта на каждый вектор, 256 прерываний, с 0-ого по 255-ое. Зная номер вектора прерывания, можно в различных режимах вычислить смещение в IDTR. Чем меньше номер линнии запроса прерывания, тем выше приоритет. В регистре флагов можно разрешить или запретить аппаратные прерывания (флаг IF)

Внутренняя структура контролера прерываний

INTA - выход МП INTR - вход МП

1) - поступившие запросы зарегистрированы. 2) - в регистре 0 - пропускает, 1- запрещает проход сигнала 3) - МП в состоянииобрботки 4) - МП смотрит на IF (запрещены или нет аппаратные прерывания), сбрасывает бит в регистре обслуживания, обработка, все остальные аппаратные прерывания запрещены.

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

В IDTR - три типа дескрипторов - прерывания, ловушки, задачи.

Программные прерывания

можно вызвать любой обработчичк прерываний - команда int. при системном вызове: 1) - переход в привелегированный режим 2) - нужна высокая скорость обработки 3) - стандарный интерфейс вызова процедур 4) - расширить номенклатуру системных вызовов 5) - обеспечение контроля ОС за выполнением прерывания

В большинстве ОС обработка прерываний происходит централизовано. При любом системном вызове вызывается единственный обработчик - int 2eh (для Intel) int 2eh - вызывает диспетчер устройств, который определяет, что делать дальше.

10. Системные вызовы

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

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

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

11. Процесс, поток.

12. Создание процессов и потоков

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

Планирование процессов и потоков

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

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

⇐ Предыдущая 1 234 5 6 7 Следующая ⇒