Некоммерческое акционерное общество
АЛМАТИНСКИЙ УНИВЕРСИТЕТ ЭНЕРГЕТИКИ И СВЯЗИ
Кафедра инженерной кибернетики
СИСТЕМНОЕ ПРОГРАММИРОВАНИЕ
Методические указания к выполнению курсовой работы
для студентов всех форм обучения
специальности 5B070200 – Автоматизация и управление
Алматы 2011
СОСТАВИТЕЛИ: Сябина Н.В. Методические указания к выполнению курсовой работы для студентов всех форм обучения специальности 5B070200 – «Автоматизация и управление». – Алматы: АУЭС, 2011 – 27 с.
Для проверки знаний студентов, полученных в результате изучения тем для самостоятельной работы, в курсе «Системное программирование» предусмотрена курсовая работа.
Настоящие методические указания предназначены в помощь студентам специальности 5B070200 – «Автоматизация и управление» и содержат варианты заданий по некоторым предназначенным для самостоятельного изучения темам курса, а также рекомендации по выполнению курсовой работы. В приложении приводится пример интерфейса программы, разработанной на кафедре для одного из вариантов курсовой работы.
Ил. 7, табл. 4, прилож. 1, библиогр. – 17 назв.
Рецензент: канд. техн. наук, проф. Б.Д.Хисаров
Печатается по плану издания некоммерческого акционерного общества «Алматинский институт энергетики и связи» на 2008 г.
© НАО «Алматинский университет энергетики и связи», 2011 г.
Cв.план 2008 г., поз. 23
1 Варианты заданий и рекомендации к выполнению курсовой работы
Современная классификация программных продуктов предусматривает его разделение на системное (hardware), промежуточное (middleware) и прикладное (software) программное обеспечение (ПО) [1, 2].
Системная программа – это программа, предназначенная для поддержания работоспособности системы обработки информации или повышения эффективности ее использования. Системное ПО подразделяется на системные управляющие и системные обслуживающие программы (утилиты).
Область программирования, которая связана с управлением техническими средствами ПК и организацией работы программных систем называется системным программированием. Системное программирование от прикладного отличает его машинная зависимость, так как системные программы тесно связаны с архитектурой и структурой компьютера, для которого они созданы.
К задачам системного программирования относят разработку систем ассемблирования, загрузчиков и программ связывания, макропроцессоров, компиляторов, операционных систем, а также драйверов.
Целью настоящей курсовой работы является изучение структуры и принципов работы системного программного обеспечения, а также получить практические навыки их разработки.
1.1 Разработка резидентной программы
1.1.1 Понятие резидентной программы
Резидентными называются программы, постоянно находящиеся в оперативной памяти компьютера [8, 9]. В специальной литературе за ними закрепилось также название TSR-программы - по наименованию функции DOS "Завершить и оставить резидентной" (Terminate and Stay Resident). Находясь постоянно в оперативной памяти, TSR-программа, большую часть времени является неактивной, а компьютер выполняет другие (системные и пользовательские) программы.
Существует несколько типов задач, при решении которых традиционно используются резидентные программы. Чаще всего такие программы пишутся для поддержки дополнительных устройств ввода-вывода, подключаемых к компьютеру: принтера, сканера, видеокамеры, джойстика, графического планшета и т.д. Хотя, следует заметить, что для обслуживания дополнительной аппаратуры более гибкими и эффективными средствами являются загружаемые драйверы устройств. Применение резидентных программ не обязательно связано с дополнительными устройствами. TSR-программы также позволяют расширить возможности пользовательского интерфейса: русификаторы, наборы дополнительных шрифтов, программы-секретари, резидентные калькуляторы, справочники, программы-корректоры, системы обработки текстов, печать со спулингом, отладчики, гасители экрана. В свое время за счет использования резидентных программ, возможности однопрограммной операционной системы MS-DOS расширялись, в некотором смысле, до мультипрограммной, поскольку в памяти одновременно сосуществуют фоновая программа и TSR-программа, активизирующиеся поочередно.
Типичная TSR-программа вызывается каким-либо внешним событием, например, нажатием определенной комбинации клавиш. Активизация резидента прерывает выполнение текущей программы на время его работы. После окончания работы резидент возвращает управление прерванной программе и становится неактивным до следующего вызова. Прерванный процесс может быть обычной программой, TSR-программой или самой операционной системой.
Для написания корректной резидентной программы необходимо владеть базовыми знаниями об архитектуре компьютера, системе прерываний и механизмах их перехвата. В частности, средства для чтения и установки векторов прерываний входят в состав библиотечных функций языка С: функции getvect() и setvect().
Очень часто активизация TSR-программы инициируется нажатием закрепленной за ней ("горячей") клавиши или комбинации клавиш, примером таких программ могут быть программы копирования экрана или резидентные словари и справочники. Из всего класса TSR-программ иногда выделяют подкласс, называемый резидентными обработчиками прерываний (ISR - Interrupt Service Resident) - программы, применяющиеся обычно для обслуживания внешних устройств и активизирующиеся по программному прерыванию подобно программам BIOS (например, драйвер мыши MOUSE.COM). ISR-программы, как правило, проще программ "горячей клавиши", так как моменты обращения к ним более предсказуемы.
1.1.2 Типовая структура TSR-программы
Обыкновенные нерезидентные программы не имеют четко выраженной структуры. Загруженная в память компьютера программа предваряется префиксом программного сегмента PSP – областью, которая строится операционной системой перед телом каждой программы (см. рисунок 1а). Она содержит различные поля, используемые системой для управления выполнением программы.
Загруженная в память программа, готовая стать резидентной, тоже имеет свой префикс программного сегмента, а ее тело можно разделить на транзитную и резидентную части (см. рисунок 1б).
а) б)
|
Тело программы |
|
Транзитная часть |
|
|
Резидентная часть |
|
|
Префикс программного сегмента PSP |
|
Префикс программного сегмента PSP |
Рисунок 1 – Структура программы: а) нерезидентной; б) резидентной
Транзитная часть программы выполняется один раз при запуске программы. В ней содержится код, осуществляющий перехват прерываний, а также необходимые данные. Завершается транзитная программа одной из функций, оставляющей программу в памяти резидентной. Некоторые языки высокого уровня содержат специальные функции для того, чтобы оставить программы резидентными в памяти. Например, в языке С для этой цели используется функция keep().
Процесс первоначального исполнения резидента как обыкновенной программы, сопровождаемый перехватом прерываний, называется инициализацией TSR-программы. После завершения инициализации транзитная часть, как правило, становится ненужной и выбрасывается из памяти.
В памяти компьютера остаются резидентная часть программы и префикс программного сегмента PSP. Если TSR-программа не будет работать с файлами, то область PSP становится лишней и ее можно использовать для хранения данных.
1.1.3 Особенности написания резидентной программы
Существуют некоторые приемы и рецепты для грамотного написания резидентных программ, корректно ведущих себя в памяти.
Резидентная программа ни в коем случае не должна допускать своего повторного запуска, так как это может привести систему к краху. Поэтому в первую очередь следует определить, имеется или нет в памяти копия программы. С этой целью, например, применяется один из неиспользуемых векторов прерываний. При своем старте TSR-программа проверяет, не указывает ли один из этих векторов на сигнатуру (уникальную запись в теле резидентной программы) в памяти. Если хотя бы один такой вектор существует, то в памяти уже есть копия программы. В этом случае программа должна выдать сообщение о невозможности повторной инициализации и завершиться. Если программа не находит вектора, указывающего на сигнатуру, то это означает, что программа запущена впервые. Однако этот способ не является идеальным.
TSR-программа запускается так же, как и любая другая программа. Но те действия, для которых она предназначена, программа должна выполнять не при запуске, а по прерыванию или по нажатию "горячей клавиши". Таким образом, действия, выполняемые при запуске программы должны только обеспечить условия для ее оставления резидентной и ее последующего функционирования в качестве резидентной.
В качестве процедуры, запускающей прикладную часть резидентной программы, обычно выбирают прерывание от таймера. Поскольку аппаратное прерывание от таймера происходит через фиксированное время, оно может оперативно реагировать на запрос об активизации основного модуля резидента.
Помимо рассмотренных особенностей разработки, также следует учитывать:
а) состояние флага занятости;
б) дисковое прерывание;
в) прерывания по нажатию Ctrl+C и Ctrl+Break;
г) прерывание критической ошибки;
д) прерывание по делению на нуль.
В любой резидентной программе необходимо предусмотреть механизм полного завершения работы и выгрузки из памяти компьютера. В этом случае TSR-программа должна проделать все то, что обычно совершает операционная система для завершения нерезидентных программ. Однако не все TSR-программы предусматривают свою выгрузку, то есть удаление из памяти, в этом случае удалить программу можно только перезагрузив систему.
Алгоритм завершения у разных резидентных программ может сильно различаться, но, как правило, его можно разбить на несколько четких последовательных шагов:
а) к моменту самоуничтожения в памяти резидент обязательно должен закрыть все открытые файлы, если таковые имелись;
б) если TSR-программа переключала PSP, то она должна опять установить операционную систему на PSP прерванного процесса;
в) резидент должен восстановить вектора перехваченных прерываний в первоначальное состояние, если это возможно;
г) выгрузить резидента, возвратив память, которую занимала TSR-программа и ее окружение.
Поскольку TSR-программа постоянно находится в памяти, она должна занимать в ней как можно меньше места, поэтому средством ее реализации бывает, как правило, язык Ассемблера, и всегда значительное внимание уделяется вопросам минимизации объема.
1.1.4 Варианты заданий
Разработать программу согласно выбранному варианту (см. таблицу 1), которая запускается автоматически при загрузке компьютера и сворачивается в Tray. Предусмотреть возможность выгрузки программы по требованию пользователя. При выполнении задания желательно придерживаться рекомендаций, которые даны в пунктах 1.1.1 - 1.1.3.
Таблица 1 – Задания к вариантам 1 – 11
|
№№ варианта |
Задание |
|
1 |
Разработать приложение «Калькулятор», которое позволяет выполнять как вычисление значений обычных функций (например, +, -, *, /, sin(), cos() и т.д.), так и сложных выражений, набранных с использованием вышеуказанных функций и вводимых в поле ввода пользователем. |
|
2 |
Разработать приложение для пользователя «Будильник», которое позволяет установить время сигнала, выбрать мелодию из предложенного набора и воспроизвести ее в указанное время. |
|
3 |
Разработать приложение для пользователя «Музыкальный альбом», позволяющее пользователю выбирать и прослушивать музыку на фоне работы с другим приложением. |
|
4 |
Разработать приложение «Журнал задач», которое бы отображало список запущенных приложений и время их запуска. |
|
5 |
Разработать приложение «History», которое бы отображало список использовавшихся пользователем приложений, время их запуска и завершения. |
|
6 |
Разработать приложение «DirectoryTree», которое по требованию пользователя отображало бы дерево каталогов и показывало размер выбранного диска (папки). |
|
7 |
Разработать приложение «Hello!», которое при запуске офисных приложений выводило бы приветствие пользователю. Предусмотреть возможность изменения текста приветствия по желанию пользователя. |
|
8 |
Разработать гаситель экрана, параметры которого (время запуска, условия завершения, видеоэффект) выбирает пользователь в окне настройки. |
|
9 |
Разработать приложение «FindWindow», которое позволит пользователю контролировать запущенные приложения и осуществлять поиск нужного окна. |
|
10 |
Разработать приложение «TrojanKiller», которое осуществляло бы проход дерева каталогов с проверкой размера файлов и могло бы использоваться как дополнительное средство борьбы с троянскими программами. |
|
11 |
Разработать приложение «Espionage», которое осуществляло бы автоматическое скрытое копирование содержимого съемного диска сразу же, как только устройство определилось системой. При этом пиктограмма должна отображать на панели задач присутствие некоторого нейтрального приложения. |
1.2 Процессы и управление ресурсами
1.2.1 Тупики и борьба с ними
Пусть несколько процессов конкурируют за обладание конечным числом ресурсов. Если запрашиваемый процессом ресурс недоступен, то операционная система переводит данный процесс в состояние ожидания. В случае, когда требуемый ресурс удерживается другим ожидающим процессом, первый процесс не сможет сменить свое состояние. Такая ситуация называется тупиком (deadlock) [3, 4, 5, 6]. Говорят, что в мультипрограммной системе процесс находится в состоянии тупика, если он ожидает события, которое никогда не произойдет. Системная тупиковая ситуация, или «зависание системы», является следствием того, что один или более процессов находятся в состоянии тупика или в состоянии взаимоблокировки. В общем случае проблема тупиков эффективного решения не имеет.
Например, два процесса осуществляют вывод с ленты на принтер. Один из них успел монополизировать ленту и претендует на принтер, а другой монополизировал принтер и претендует на ленту. В результате оба процесса оказываются заблокированными в ожидании второго ресурса. Описанная ситуация иллюстрирует пример взаимоблокировки, возникающей при работе с так называемыми выделенными устройствами.
Тупики, однако, могут иметь место как на аппаратных, так и на программных ресурсах, а также могут быть вызваны ошибками программирования. Например, процесс может напрасно ждать открытия семафора, потому что в некорректно написанном приложении эту операцию забыли предусмотреть. Другой причиной бесконечного ожидания может быть дискриминационная политика по отношению к некоторым процессам. Однако чаще всего событие, которого ждет процесс в тупиковой ситуации, – освобождение ресурса.
Ресурсами могут быть как устройства, так и данные. Некоторые ресурсы допускают разделение между процессами, то есть являются разделяемыми ресурсами. Например, память, процессор, диски могут коллективно использоваться процессами. Другие не допускают разделения, то есть являются выделенными (неделимыми), например, лентопротяжное устройство. К взаимоблокировке может привести использование как выделенных, так и разделяемых ресурсов.
Например, чтение с разделяемого диска может одновременно осуществляться несколькими процессами, тогда как запись предполагает исключительный доступ к данным на диске. Можно считать, что часть диска, куда происходит запись, выделена конкретному процессу. Следовательно, тупики связаны с выделенными ресурсами, то есть возникают тогда, когда процессу предоставляется эксклюзивный доступ к устройствам, файлам и другим ресурсам.
Традиционная последовательность событий при работе с ресурсом состоит из запроса, использования и освобождения ресурса. Тип запроса зависит от природы ресурса и от операционной системы. Запрос может быть явным или неявным. Обычно, если ресурс занят и запрос отклонен, запрашивающий процесс переходит в состояние ожидания.
Условия возникновения тупиков были сформулированы Коффманом, Элфиком и Шошани в 1970 г. Различают:
1) условие взаимоисключения (mutual exclusion): одновременно использовать ресурс может только один процесс;
2) условие ожидания ресурсов (hold and wait): процессы удерживают уже выделенные им ресурсы и могут запрашивать другие ресурсы;
3) условие неперераспределяемости (no preemtion): выделенный ранее ресурс не может быть принудительно отобран у процесса и может быть освобожден только этим процессом;
4) условие кругового ожидания (circular wait): существует кольцевая цепь процессов, в которой каждый процесс ждет доступа к ресурсу, удерживаемому другим процессом цепи.
Для образования тупика необходимым и достаточным является выполнение всех четырех условий.
Проблема тупиков инициировала много интересных исследований в области информатики. Очевидно, что условие циклического ожидания отличается от остальных. Первые три условия формируют правила, существующие в системе, тогда как четвертое условие описывает ситуацию, которая может сложиться при определенной неблагоприятной последовательности событий. Поэтому методы предотвращения взаимоблокировок ориентированы на нарушение первых трех условий путем введения ряда ограничений на поведение процессов и способы распределения ресурсов. Методы обнаружения и устранения менее консервативны и сводятся к поиску и разрыву цикла ожидания ресурсов.
Таким образом, можно выделить следующие основные направления борьбы с тупиками:
1) игнорирование проблемы в целом. Простейший подход – не замечать проблему тупиков. Для того чтобы принять такое решение, необходимо оценить вероятность возникновения взаимоблокировки и сравнить ее с вероятностью ущерба от других отказов аппаратного и программного обеспечения. Проектировщики обычно не желают жертвовать производительностью системы или удобством пользователей для внедрения сложных и дорогостоящих средств борьбы с тупиками.
Любая операционная система, имеющая в ядре ряд массивов фиксированной размерности, потенциально страдает от тупиков, даже если они не обнаружены. Фактически каждая таблица (например, таблица открытых файлов, таблица процессов) являются ограниченными ресурсами. Заполнение всех записей таблицы процессов может привести к тому, что очередной запрос на создание процесса может быть отклонен. При неблагоприятном стечении обстоятельств несколько процессов могут выдать такой запрос одновременно и оказаться в тупике.
Подход большинства популярных операционных систем (Unix, Windows и др.) состоит в том, чтобы игнорировать данную проблему в предположении, что маловероятный случайный тупик предпочтительнее, чем нелепые правила, заставляющие пользователей ограничивать число процессов, открытых файлов и т. п. Сталкиваясь с выбором между строгостью и удобством, трудно найти решение, которое устраивало бы всех;
2) предотвращение тупиков. Цель предотвращения тупиков – обеспечить условия, исключающие возможность возникновения тупиковых ситуаций. Большинство методов связано с предотвращением одного из условий возникновения взаимоблокировки. Система, предоставляя ресурс в распоряжение процесса, должна принять решение, безопасно это или нет. Существуют алгоритмы, позволяющие избежать тупиков, но только в случае, если определенная информация известна заранее:
а) предотвращение тупиков путем тщательного распределения ресурсов (алгоритм банкира). Алгоритм банкира, предложенный Дейкстрой, базируется на так называемых безопасных или надежных состояниях (safe state).
Безопасное состояние – это такое состояние, для которого имеется, по крайней мере, одна последовательность событий, не приводящая к взаимоблокировке. Текущее состояние системы называется надежным, если операционная система может обеспечить всем процессам их выполнение в течение конечного времени. Термин ненадежное состояние не предполагает, что обязательно возникнут тупики, а лишь говорит о том, что в случае неблагоприятной последовательности событий система может зайти в тупик.
Модель алгоритма основана на действиях банкира, который, имея в наличии капитал, выдает кредиты. Суть алгоритма заключается в следующем. Предположим, что у системы в наличии n устройств, например лент. Операционная система принимает запрос от пользовательского процесса, если его максимальная потребность не превышает n. Пользователь гарантирует, что если операционная система в состоянии удовлетворить его запрос, то все устройства будут возвращены системе в течение конечного времени. В соответствии с алгоритмом банкира выделение устройств возможно, только если состояние системы остается надежным.
Пример 1.1 – Определение надежности системы.
Имеется система с 3 пользователями и 11 устройствами, где 9 устройств задействовано, а 2 имеется в резерве. Пусть текущая ситуация такова:
|
|
Максимальная потребность в ресурсах |
Выделенное пользователям количество ресурсов |
|
Пользователь 1 |
9 |
6 |
|
Пользователь 2 |
10 |
2 |
|
Пользователь 3 |
3 |
1 |
Данное состояние надежно. Возможны следующие действия системы:
- удовлетворить запросы Пользователя 3;
- дождаться, когда он закончит работу и освободит свои три устройства;
- обслужить первого и второго пользователей.
То есть система удовлетворяет только те запросы, которые оставляют ее в надежном состоянии, и отклоняет остальные.
Достоинством алгоритма является то, что при его использовании нет необходимости в перераспределении ресурсов и откате процессов назад. Однако использование этого метода требует выполнения ряда условий:
- число пользователей и число ресурсов фиксировано;
- число работающих пользователей должно оставаться постоянным;
- клиенты должны гарантированно возвращать ресурсы;
- заранее должны быть указаны максимальные требования процессов к ресурсам (чаще всего такая информация отсутствует).
Наличие таких жестких и зачастую неприемлемых требований в большинстве случаев диктует выбор других решений проблемы взаимоблокировки;
б) предотвращение тупиков за счет нарушения условий возникновения тупиков. В условиях отсутствия информации о будущих запросах единственный способ избежать взаимоблокировки – добиться невыполнения хотя бы одного из четырех условий возникновения тупиков:
- нарушение условия взаимоисключения. В общем случае избежать взаимоисключений невозможно. Доступ к некоторым ресурсам должен быть исключительным. Тем не менее, некоторые устройства удается обобществить.
Допустим, что вывод на принтер пытаются осуществить несколько процессов. Во избежание хаоса следует организовать промежуточное формирование всех выходных данных процесса на диске, то есть разделяемом устройстве. Лишь один системный процесс, называемый сервисом или демоном принтера, отвечающий за вывод документов на печать по мере освобождения принтера, реально с ним взаимодействует. Такая схема называется спулингом (spooling). Таким образом, принтер становится разделяемым устройством, и тупик для него устранен.
К сожалению, не для всех устройств и не для всех данных можно организовать спулинг. Следствием такой модели может быть потенциальная тупиковая ситуация из-за конкуренции за дисковое пространство для буфера спулинга. Однако в той или иной форме эта схема применяется часто;
- нарушение условия ожидания дополнительных ресурсов. Условия ожидания ресурсов можно избежать, потребовав выполнения стратегии двухфазного захвата: в первой фазе процесс должен запрашивать все необходимые ему ресурсы сразу (до тех пор, пока они не предоставлены, процесс не может продолжать выполнение); если в первой фазе некоторые ресурсы, которые были нужны данному процессу, уже заняты другими процессами, он освобождает все выделенные ему ресурсы и пытается повторить первую фазу.
Таким образом, цель способа – заставить все процессы затребовать нужные им ресурсы перед выполнением ("все или ничего"). Если система в состоянии выделить процессу все необходимое, он может работать до завершения. Если хотя бы один из ресурсов занят, процесс будет ждать. В целом подобный подход приводит к неэффективному использованию компьютера, поскольку, перечень будущих запросов к ресурсам редко удается спрогнозировать. Если такая информация есть, то можно воспользоваться алгоритмом банкира. Кроме того, описываемый подход противоречит принципу модульности в программировании, поскольку приложение должно знать о предполагаемых запросах к ресурсам во всех модулях;
- нарушение принципа отсутствия перераспределения. Если бы можно было отбирать ресурсы у владеющих ими процессов до завершения этих процессов, то удалось бы добиться невыполнения третьего условия возникновения тупиков. Однако отбирать у процессов можно только те ресурсы, состояние которых легко сохранить, а позже восстановить, например состояние процессора. Если процесс в течение некоторого времени использует определенные ресурсы, а затем освобождает эти ресурсы, он может потерять результаты работы, проделанной до настоящего момента. Наконец, следствием данной схемы может быть дискриминация отдельных процессов, у которых постоянно отбирают ресурсы;
- нарушение условия кругового ожидания. Один из способов – упорядочить ресурсы. Например, присвоить всем ресурсам уникальные номера и потребовать, чтобы процессы запрашивали ресурсы в порядке их возрастания. Тогда круговое ожидание возникнуть не может. После последнего запроса и освобождения всех ресурсов можно разрешить процессу опять осуществить первый запрос. Очевидно, что практически невозможно найти порядок, который удовлетворит всех. Другой способ атаки условия кругового ожидания – действовать в соответствии с правилом, согласно которому каждый процесс может иметь только один ресурс в каждый момент времени. Если нужен второй ресурс – освободи первый. Очевидно, что для многих процессов это неприемлемо. Таким образом, технология предотвращения циклического ожидания, как правило, неэффективна и может без необходимости закрывать доступ к ресурсам.
в) обнаружение тупиков. Обнаружение взаимоблокировки сводится к фиксации тупиковой ситуации и выявлению вовлеченных в нее процессов. Для этого производится проверка наличия циклического ожидания в случаях, когда выполнены первые три условия возникновения тупика. Методы обнаружения активно используют графы распределения ресурсов.
Пример 2 – Обнаружение тупиков.
Пусть в системе 5 процессов конкурируют за 3 ресурса. В определенный момент времени процессы находятся в следующем состоянии:
|
|
Удерживает |
Ожидает |
|
Процесс P1 |
- |
ресурс R1 |
|
Процесс P2 |
ресурс R2 |
ресурс R1 |
|
Процесс P3 |
ресурс R1 |
ресурс R3 |
|
Процесс P4 |
- |
ресурс R2 |
|
Процесс P5 |
ресурс R3 |
ресурс R2 |
Определить является ли данная ситуация тупиковой, и, если да, то какие процессы в ней участвуют.
Для решения задачи построим граф ресурсов (см. рисунок 2). Из рисунка видно, что имеется цикл, моделирующий условие кругового ожидания, и что процессы P2, P3 и P5 находятся в тупиковой ситуации.
Визуально, используя граф, легко обнаружить наличие тупика, однако нужны и формальные алгоритмы, реализуемые на компьютере. Один из таких алгоритмов описан в [3], там же можно найти ссылки на другие алгоритмы. Существуют и другие способы обнаружения тупиков, применимые в ситуациях, когда имеется несколько ресурсов каждого типа. Так в [11] описан способ, называемый редукцией графа распределения ресурсов, а в [3] – матричный алгоритм.
г) восстановление после тупиков. Обнаружив тупик, можно вывести из него систему, нарушив одно из условий существования тупика. При этом возможно несколько процессов частично или полностью потеряют результаты проделанной работы. Сложность восстановления обусловлена рядом факторов:
- в большинстве систем нет достаточно эффективных средств, чтобы приостановить процесс, вывести его из системы и возобновить впоследствии с того места, где он был остановлен;
- если такие средства есть, то их использование требует затрат и внимания оператора;
- восстановление после тупика может потребовать значительных усилий.
Самый простой и наиболее распространенный способ устранить тупик – завершить выполнение одного или более процессов, чтобы впоследствии использовать его ресурсы. Тогда в случае удачи остальные процессы смогут выполняться, в противном случае можно ликвидировать еще несколько процессов. После каждой ликвидации должен запускаться алгоритм обнаружения тупика. По возможности лучше ликвидировать тот процесс, который может быть без ущерба возвращен к началу (такие процессы называются идемпотентными). Например, компиляция.
В некоторых случаях можно временно отнять ресурс у текущего владельца и передать его другому процессу. Возможность отъема ресурса и его возврата процессу без ущерба зависит от природы ресурса. Подобное восстановление часто затруднительно.
В ряде систем реализованы средства отката и перезапуска или рестарта с контрольной точки (сохранение состояния системы в какой-то момент времени). Если известно, что тупик вероятен, можно периодически организовывать для процессов контрольные точки.
Когда тупик обнаружен, видно, какие ресурсы вовлечены в цикл кругового ожидания. Чтобы осуществить восстановление, процесс, который владеет таким ресурсом, должен быть отброшен к моменту времени, предшествующему его запросу на этот ресурс.
Таким образом, возникновение тупиков является потенциальной проблемой любой операционной системы. Они возникают, когда имеется группа процессов, каждый из которых пытается получить исключительный доступ к некоторым ресурсам и претендует на ресурсы, принадлежащие другому процессу. В итоге все они оказываются в состоянии бесконечного ожидания. С тупиками можно бороться, можно их обнаруживать, избегать и восстанавливать систему после тупиков. Однако цена подобных действий высока и соответствующие усилия должны предприниматься только в системах, где игнорирование тупиковых ситуаций приводит к катастрофическим последствиям.
1.2.2 Варианты заданий
1.2.2.1 Разработать программу, которая позволяет обнаружить и предупредить возникновение тупиковой ситуации в системе. Исходные данные выбрать в соответствии с таблицей 2. Предполагается, что каждый процесс освобождает удерживаемый ресурс в разные моменты времени (random). Изменится ли ситуация кардинально, если освобождение ресурсов будет происходить одновременно у всех процессов? Предусмотреть возможность просмотра пользователем на экране текущего состояния процесса и сохранение его истории в журнале.
1.2.2.2 Имеется система с n пользователями и m устройствами, где k устройств задействовано, а p имеется в резерве. В соответствии с текущей ситуацией (см. таблицу 3) определить надежность состояния и подобрать наиболее оптимальный вариант возможных последующих действий системы. Предусмотреть возможность получения пользователем информации о текущем состоянии процесса и сохранение ее в журнале.
Таблица 2 – Задания к вариантам 11 – 16
|
№№ варианта |
Текущее состояние системы |
||||||||||||||||||||||||
|
11 |
|
||||||||||||||||||||||||
|
12 |
|
||||||||||||||||||||||||
|
13 |
|
||||||||||||||||||||||||
|
14 |
|
||||||||||||||||||||||||
|
15 |
|
||||||||||||||||||||||||
|
16 |
|
Таблица 3 – Задания к вариантам 17 – 21
|
№№ варианта |
Текущее состояние системы |
|||||||||||||||||||||
|
17 |
В системе 5 пользователей и 12 устройств, где 9 устройств задействовано, а 3 имеется в резерве.
|
|||||||||||||||||||||
|
18 |
В системе 6 пользователей и 12 устройств, где 10 устройств задействовано, а 2 имеется в резерве.
|
|||||||||||||||||||||
|
19 |
В системе 6 пользователей и 12 устройств, где 10 устройств задействовано, а 2 имеется в резерве.
|
|||||||||||||||||||||
|
20 |
В системе 5 пользователей и 12 устройств, где 9 устройств задействовано, а 3 имеется в резерве.
|
|||||||||||||||||||||
|
21 |
В системе 5 пользователей и 11 устройств, где 8 устройств задействовано, а 3 имеется в резерве.
|
1.3 Антивирусная безопасность компьютерных систем
1.3.1 Компьютерные вирусы
Теоретические основы создания компьютерных вирусов были заложены в 40-х годах прошлого столетия американским ученым Джоном фон Нейманом, который также известен как автор базовых принципов работы современного компьютера. Известно, что первые вирусы создавались исключительно с научной целью и не были предназначены для нанесения вреда. Наоборот, с помощью такого вида программ ученые собирались моделировать и изучать поведение реальных природных явлений и систем. Как и в случае настоящего биологического вируса, его компьютерный аналог наделен главным отличительным свойством - способностью к самораспространению - прямо или посредством других механизмов (программ). Так же как вирус гриппа использует в своей жизнедеятельности клетки человека, компьютерная программа живет и размножается в файлах операционной системы и оперативной памяти компьютера. Первый настоящий компьютерный вирус Pervading Animal появился в конце 1960-х годов и представлял собой игру, написанную с непреднамеренной ошибкой. Первую глобальную эпидемию вызвал Brain (1986 год), по совместительству первый вирус для IBM-совместимых компьютеров, а также стелс-вирус. Он был написан в Пакистане с целью определения уровня пиратства в стране.
Однако созданная учеными технология быстро и в полной мере была оценена преступниками, а стремительное увеличение объемов памяти современных компьютеров, постоянный рост мощности информационных потоков, развитие Интернет и повсеместная популярность электронной почты открыло широкие горизонты для вирусописателей. Первым сетевым червем стал Creeper (конец 1970-х), умевший самостоятельно выйти в сеть через модем и записать свою копию на удаленной машине. Первый троян - Aids Information Diskette (1989 год) сразу вызвал эпидемию: будучи зараженным такой компьютер после 90 перезагрузок операционной системы показывал пользователю требование перевести на указанный в нем адрес $189, при этом все остальные файлы жесткого диска становились недоступны.
За эволюцией вычислительной техники последовало широкое распространение компьютеризированных систем в самых разнообразных областях - на биржах, в промышленных товарах, банковской сфере, появились интернет-магазины и электронные деньги. Как следствие, увеличилось число приманок для электронных грабителей: конфиденциальная информация стала записываться не в бумажный блокнот, запертый в сейф, а на жесткий диск компьютера человека, который часто проводит время в Интернет. Для покупки начали использоваться не наличные, переходящие кассиру в магазине из рук в руки, а биты данных, передаваемые по открытым каналам связи. При этом развитие различных технологий вредоносного воздействия также не стояло на месте.
Таким образом, на основе известной информации [14, 15, 17] можно сформулировать следующие положения:
1) любая компьютерная программа потенциально может быть инфицирована;
2) любой компьютер, способный к обмену информацией (через дискеты, лазерные диски, по сети или другим беспроводным каналам связи) потенциально может быть инфицирован;
3) в наибольшей степени подвержены заражению компьютеры под управлением операционной системы семейства Microsoft Windows;
4) существуют вирусы для мобильных телефонов;
5) для проверки работоспособности установленной антивирусной защиты существует специальный тестовый вирус – Eicar [16].
Среди вредоносных программ выделяют четыре основных типа:
а) вирусы;
б) черви;
в) трояны;
г) другие (условно опасные программы riskware, adware, pornware; шпионские программы spyware, хакерские утилиты и злые шутки).
Каждый из типов вредоносных программ отличается от других методом распространения, средой обитания и наносимым вредом. Специальный класс вредоносных явлений, рассчитанных на очень доверчивых пользователей, составляют вирусные шутки и мистификации.
Основанием для подозрения на наличие вируса в системе могут служить:
а) внезапное и несанкционированное изменение настроек браузера;
б) необычные всплывающие окна и другие сообщения;
в) неожиданный несанкционированный дозвон в Интернет;
г) самопроизвольное блокирование антивирусной программы;
д) невозможность загрузки файлов с веб-сайтов антивирусных компаний;
е) необоснованные на первый взгляд сбои в работе операционной системы или других программ;
ж) почтовые уведомления с заслуживающих доверие сайтов об отправке пользователем инфицированных сообщений.
При подозрении на заражение системы вирусом в первую очередь необходимо:
а) проверить наличие в оперативной памяти подозрительных процессов;
б) проанализировать элементы автозапуска: в меню автозагрузки, в системном реестре Windows, в конфигурационных файлах win.ini и system.ini;
в) вывести список всех сетевых соединений и убедиться в отсутствии подозрительной сетевой активности;
г) ознакомиться с последними новостями на сайтах антивирусных компаний и в случае оглашения эпидемии какого-либо вируса сравнить его проявления и теми, которые наблюдаются на компьютере;
д) проверить отсутствие на жестком диске подозрительных файлов (в соответствии с описаниями последних вирусов).
1.3.2 Антивирусная защита
Антивирус - программное средство, предназначенное для борьбы с вирусами. Основными задачами антивируса являются:
1) препятствование проникновению вирусов в компьютерную систему;
2) обнаружение наличия вирусов в компьютерной системе;
3) устранение вирусов из компьютерной системы без нанесения повреждений другим объектам системы;
4) минимизация ущерба от действий вирусов.
Антивирусы отличаются друг от друга используемыми технологиями и условиями эксплуатации. Из анализа задач можно сделать вывод о том, что препятствование проникновению вредоносного кода должно осуществляться непрерывно, тогда как обнаружение вредоносного кода в существующей системе - разовое мероприятие. Следовательно, средства, решающие эти две задачи должны функционировать по-разному.
Таким образом, антивирусы можно разделить на две большие категории:
1) предназначенные для непрерывной работы - к этой категории относятся средства проверки при доступе, почтовые фильтры, системы сканирования проходящего трафика Интернет, другие средства, сканирующие потоки данных;
2) предназначенные для периодического запуска - различного рода средства проверки по запросу, предназначенные для однократного сканирования определенных объектов. К таким средствам можно отнести сканер по требованию файловой системы в антивирусном комплексе для рабочей станции, сканер по требованию почтовых ящиков и общих папок в антивирусном комплексе для почтовой системы.
Антивирусный комплекс - набор антивирусов, использующих одинаковое антивирусное ядро (ядра), предназначенный для решения практических проблем по обеспечению антивирусной безопасности компьютерных систем и содержащий средства обновления антивирусных баз. Антивирусное ядро - реализация механизма сигнатурного сканирования и эвристического анализа на основе имеющихся сигнатур вирусов. Помимо этого антивирусный комплекс дополнительно может включать в себя поведенческие анализаторы и ревизоры изменений. В качестве вспомогательной утилиты антивирусный комплекс может содержать планировщик заданий. Исходя из текущей необходимости, в средствах защиты выделяют следующие типы антивирусных комплексов:
1) антивирусный комплекс для защиты рабочих станций;
2) антивирусный комплекс для защиты файловых серверов;
3) антивирусный комплекс для защиты почтовых систем;
4) антивирусный комплекс для защиты шлюзов.
1.3.3 Методы антивирусной защиты
Из всех методов антивирусной защиты можно выделить две основные группы:
1) сигнатурные методы - точные методы обнаружения вирусов, основанные на сравнении файла с известными образцами вирусов;
2) эвристические методы - приблизительные методы обнаружения, которые позволяют с определенной вероятностью предположить, что файл заражен.
Сигнатурный анализ заключается в выявлении характерных идентифицирующих черт каждого вируса и поиска вирусов путем сравнения файлов с выявленными чертами. Сигнатурой вируса будет считаться совокупность черт, позволяющих однозначно идентифицировать наличие вируса в файле (включая случаи, когда файл целиком является вирусом). Все вместе сигнатуры известных вирусов составляют антивирусную базу. Задачу выделения сигнатур решают эксперты в области компьютерной вирусологии, способные выделить код вируса из кода программы и сформулировать его характерные черты в форме, наиболее удобной для поиска. В наиболее простых случаях могут применяться специальные автоматизированные средства выделения сигнатур, например, в случае несложных по структуре троянов или червей, которые не заражают другие программы, а целиком являются вредоносными программами. Достоинством сигнатур является точное и гарантированное определение типа вируса. Недостаток заключается в том, что для получения сигнатуры необходимо иметь образец вируса, следовательно, сигнатурный метод непригоден для защиты от новых вирусов.
Суть эвристических методов состоит в том, что решение проблемы основывается на некоторых правдоподобных предположениях, а не на строгих выводах из имеющихся фактов и предпосылок. Рассмотрим примеры различных эвристических методов:
1) поиск вирусов, похожих на известные. Анализ основывается на предположении, что новые вирусы часто оказываются похожи на какие-либо из уже известных. Метод заключается в поиске файлов, которые не полностью, но очень близко соответствуют сигнатурам известных вирусов. Достоинством является предоставляемая методом возможность обнаружить новые вирусы еще до того, как для них будут выделены сигнатуры. Недостатки метода: вероятность ошибочного определения наличие в файле вируса, когда на самом деле файл чист (ложное срабатывание); невозможность лечения; низкая эффективность.
2) поиск вирусов, выполняющих подозрительные действия. Метод, основанный на эвристике, исходит из предположения, что вредоносные программы так или иначе стремятся нанести вред компьютеру. Метод основан на выделении основных вредоносных действий, таких как удаление файла, запись в файл, запись в определенные области системного реестра, открытие порта на прослушивание, перехват вводимых с клавиатуры данных, рассылка писем и т.д. Выполнение каждого такого действия по отдельности не является поводом считать программу вредоносной. Но если программа последовательно выполняет несколько таких действий, например, записывает запуск себя же в ключ автозапуска системного реестра, перехватывает данные вводимые с клавиатуры и с определенной частотой пересылает эти данные на какой-то адрес в Интернет, значит она, по меньшей мере, подозрительна. Основанный на этом принципе эвристический анализатор должен постоянно следить за действиями, которые выполняют программы. Преимуществом описанного метода является возможность обнаруживать неизвестные ранее вредоносные программы, даже если они не очень похожи на уже известные. Недостатки те же, что и в предыдущем методе.
Практически любой антивирус сегодня использует все известные методы обнаружения вирусов. Однако для обеспечения эффективности антивирусных средств требуют я дополнительные модули, выполняющие вспомогательные функции [17]:
1) модуль обновления, который осуществляет доставку сигнатур с сервера компании-разработчика на компьютеры всех пользователей. Модули обновления разных антивирусов весьма похожи друг на друга и отличаются типами протоколов, которые они могут использовать при загрузке, и возможностями настройки действий, на случай, если источник обновлений недоступен;
2) модуль планирования - позволяет настроить периодичность выполнения регулярных действий антивируса, т.е. выбрать для каждого действия расписание, которое больше всего подходит именно для этого типа действия;
3) модуль управления - это общий интерфейсный модуль, при помощи которого можно в удобной форме получить доступ к наиболее важным функциям: настройке параметров антивирусных модулей, настройке обновлений, настройке периодического запуска обновления и проверки.
4) карантин – специальная технология, которая защищает от возможной потери данных в результате действий антивируса;
5) тестирование работы антивируса – использование специального тестового файла eicar.com для проверки антивирусной защиты, который детектируется как вирус.
1.3.4 Варианты заданий
Создать программу, демонстрирующую основные приемы работы с файловой системой и осуществление операций над файлами на примере поиска потенциально опасных программ по различным критериям (см. таблицу 4). Программа должна обеспечивать выполнение следующих функций:
1) работа программы должна регулироваться с помощью окна сохраняемых настроек;
2) в случае обнаружения подозрительного объекта запрашивать у пользователя разрешение на выполнение удаления, добавления файла в список исключений или помещения их в карантин;
3) в файле отчета программа должна сохранять сведения об обнаруженных подозрительных объектах, полный путь к файлу и результат попытки его удаления;
4) предоставлять пользователю возможность выбора режима запуска программы (запуск сканера при загрузке операционной системы, непрерывное сканирование).
Пример интерфейса аналогичной программы поиска вредоносных программ в системе в условиях отсутствия антивирусного программного обеспечения с комментариями приведен в Приложении А (см. рисунки А.1 – А.6).
Таблица 4 – Задания к вариантам 22 – 25
|
№№ варианта |
Задание |
|
22 |
Разработать программу, которая бы осуществляла поиск вредоносных программ, ориентируясь на размеры файлов. |
|
23 |
Разработать программу, которая бы осуществляла поиск вредоносных программ, сравнивая первые N символов содержимого файлов. |
|
24 |
Разработать программу, которая бы осуществляла поиск вредоносных программ на основе выявления подозрительных процессов с помощью Диспетчера задач и их выгрузку. |
|
25 |
Разработать программу, которая бы осуществляла поиск вредоносных программ на основе проверки контрольных сумм. |
2 Общие рекомендации к выполнению курсовой работы и подготовке отчета
Самостоятельная работа студента (СРС) предполагает не только проработку лекционного материала, подготовку к практическим и лабораторным занятиям, но и изучение дополнительного материала. Для проверки знаний, полученных в результате самостоятельной работы студента, в курсе «Системное программирование» предусмотрена курсовая работа. В качестве источника информации для выполнения курсовой работы следует использовать учебники, учебные пособия, методические разработки [1 - 15]. Кроме того, дополнительную информацию можно почерпнуть из периодических изданий, справочной литературы по различным программным продуктам, справочной системы каждой программы, имеющейся в памяти компьютера, а также, используя справочную систему Интернет [16, 17].
Предлагаемые варианты заданий выбираются в соответствии с рекомендациями преподавателя. Преподаватель может по своему усмотрению изменить или дополнить курсовую работу, ориентируясь на общий уровень подготовки.
Курсовая работа сдается на проверку в сроки, установленные кафедрой. Исходные и загрузочные файлы предоставляются в электронном виде (на дисках). Также необходимо приложить пояснительную записку, выполненную в соответствии со стандартом, принятом в университете, на листах формата А4 и включающую титульный лист, введение, содержание разработки, заключение, список использованной литературы. В содержание разработки следует включить постановку задачи, описание методов и средств, применяемых для решения поставленной задачи, все необходимые схемы и алгоритмы, листинги программ с комментариями, скриншоты результатов разработки. В случае если работа содержит ошибки, выполнена не в полном объеме или не соответствует выбранному варианту, она возвращается студенту для внесения исправлений. После проверки курсовая работа должна быть защищена.
Приложение А
Пример интерфейса программы поиска вредоносных программ в системе в условиях отсутствия антивирусного программного обеспечения
Программа осуществляет поиск вредоносных программ по размеру файла или по первым N символам его содержимого.
Работа программы регулируется сохраняемыми настройками.
В окне настроек (см. рисунок А.1) предусмотрена установка следующих параметров проверки:
Рисунок А.1 – Окно настроек программы
1) запись результата в файл. При включении настройки «Записывать результаты в файл» программа сохраняет сведения о найденных подозрительных объектах в файле отчета (см. рисунок А.2). В файле отчета сохраняется полный путь к файлу и результат попытки его удаления;
Рисунок А.2– Пример файла отчета
2) запрос разрешения на действие. Настройка «Запрашивать разрешение на действие» определяет, будет ли программа в случае обнаружения подозрительного объекта спрашивать пользователя о том, какое действие следует выполнить. Если настройка отключена, то программа сделает попытку самостоятельно удалить обнаруженный объект, не уведомляя при этом пользователя. При включении настройки пользователю будет выведено диалоговое окно, в котором можно выбрать действие над объектом: удалить, добавить в исключения, игнорировать (см. рисунок А.3);
Рисунок А.3 – Окно выбора действия над объектом
3) разрешение исключений. При осуществлении программой поиска вредоносных файлов, ориентируясь на их размеры, неизбежны случаи совпадения размера вредоносной программы и некоторых системных файлов. Для предотвращения попытки их удаления необходим список исключений, который визуально доступен пользователю. При отключении на стройки «Разрешить исключения» программа игнорирует этот список. При этом, чем раньше начинает создаваться список исключений, тем лучше (наиболее оптимальный вариант – сразу же после установки операционной системы на жесткий диск), поскольку это позволит исключить нанесение вреда системе;
4) запуск сканера при каждой загрузке компьютера. При включении соответствующей настройки программа сама записывается в автозагрузку (см. рисунок А.4);
Рисунок А.4 – Пример записи в Автозагрузке
5) непрерывное сканирование. Настройка позволяет после окончания проверки запустить ее заново, не прекращая процесс поиска ни на секунду. При этом после окончания каждой проверки уведомление о завершении сканирования не выдается, за счет чего у пользователя возникает иллюзия непрерывности сканирования;
6) экономия ресурсов процессора. Позволяет регулировать уровень ресурсов процессора. Если настройка установлена на минимум, то процесс проверки может оказаться довольно ресурсоемким. Такой режим подходит для того, чтобы провести относительно быструю проверку, не перегружая при этом компьютер другими задачами. Но для непрерывного сканирования такой режим не оптимален, поскольку разумнее увеличить уровень экономии ресурсов процессора, чем максимально увеличивать скорость проверки. Несмотря на то, что замедлится работа программы, пользователь не будет чувствовать неудобства, работая с ресурсоемкими приложениями при включенной фоновой проверке. В сочетании с настройкой «Непрерывное сканирование» предоставляет возможности для ее наилучшего использования;
7) сверять по первым …символам. Настройка позволяет увеличить точность проверки, уменьшив количество совпадений с системными файлами. Количество символов можно регулировать, что в результате приводит к регулированию соотношения «скорость – точность». Меньше символов – выше скорость, но ниже точность. К сожалению, настройка лишь уменьшает количество совпадений, но не исключает их полностью.
Кроме перечисленных возможностей, пользователь может воспользоваться функцией формирования списков подозрительных объектов и исключений. Для этого после нажатия кнопки «Добавить» в появившемся диалоговом окне можно выбрать файл для добавления.
В случае если программе не удалось завершить проверку вследствие возникшей системной ошибки, отключения питания или по иным причинам, существует возможность просмотреть, на каком этапе прервалась проверка с помощью специального файла (см. рисунок А.5).
Рисунок А.5 – Пример записи в файл результатов прерванной проверки
Список литературы
1. Гордеев А.В., Молчанов А.Ю. Системное программное обеспечение. – СПб.: Питер, 2002.
2. Фельдман С.К. Системное программирование на персональном компьютере. - М.: ЗАО «Новый издательский дом», 2007.
3. Таненбаум Э. Современные операционные системы. - СПб.: Питер, 2002.
4. Гордеев В.А. Операционные системы. – СПб.: Питер, 2007.
5. Назаров С.В. Операционные среды, системы и оболочки. Основы структурной и функциональной организации. – М., 2007.
6. Илюшечкин В.М. Операционные системы. - М., 2009.
7. Пирогов В.Ю. ASSEMBLER. Учебный курс. - М.: Издательство Нолидж, 2001.
8. Моор Р. Пишем резидентную программу. //Серия «В библиотеку программиста IBM PC». Выпуск 2. – Алма-Ата, Самурык, 1982.
9. Финогенов К.Г. Самоучитель по системным функциям MS-DOS. - М.: М., Горячая линия - Телеком, 2001.
10. Зубков С. В. Assembler для DOS, Windows и UNIX. - М.: ДМК Пресс; СПб.: Питер, 2004.
11. Дейтел Х.М., Дейтел П.Дж. Как программировать на С++. – М.: БИНОМ, 1999.
12. Архангельский А.Я. C++ Builder 6. Справочное пособие. Книга 1. Язык С++. – М.: Бином-Пресс, 2002.
13. Архангельский А.Я. C++ Builder 6. Справочное пособие. Книга 2. Классы и компоненты. – М.: Бином-Пресс, 2002.
14. Козлов Д.А. и др. Энциклопедия компьютерных вирусов. – М.: Солон-Р, 2001.
15. Романец Ю.В. и др. Защита информации в компьютерных системах и сетях. – М., 2001.
16. www.eicar.org.
17 www.intuit.ru.
Содержание
1 Варианты заданий и рекомендации к выполнению курсовой работы 3
1.1 Разработка резидентной программы 3
1.2 Процессы и управление ресурсами 8
1.3 Антивирусная безопасность компьютерных систем 17
2 Общие рекомендации к подготовке отчета 22
Приложение А 24
Список литературы 27