ос и с. ОСиС. 1. Классификация программного обеспечения
Скачать 2.7 Mb.
|
Примеры алгоритмов В данном разделе мы рассмотрим четыре алгоритма ядра, реализованных с использованием семафоров. Алгоритм выделения буфера иллюстрирует сложную схему блокирования, на примере алгоритма wait показана синхронизация выполнения процессов, схема блокирования драйверов реализует изящный подход к решению данной проблемы, и наконец, метод решения проблемы холостой работы процессора показывает, что нужно сделать, чтобы избежать конкуренции между процессами. Выделение буфера Алгоритм getblk работает с тремя структурами данных: заголовком буфера, хеш-очередью буферов и списком свободных буферов. Ядро связывает семафор со всеми экземплярами каждой структуры. Другими словами, если у ядра имеются в распоряжении 200 буферов, заголовок каждого из них включает в себя семафор, используемый для захвата буфера; когда процесс выполняет над семафором операцию P, другие процессы, тоже пожелавшие захватить буфер, приостанавливаются до тех пор, пока первый процесс не исполнит операцию V. У каждой хеш-очереди буферов также имеется семафор, блокирующий доступ к очереди. В однопроцессорной системе блокировка хеш-очереди не нужна, ибо процесс никогда не переходит в состояние приостанова, оставляя очередь в несогласованном (неупорядоченном) виде. В многопроцессорной системе, тем не менее, возможны ситуации, когда с одной и той же хеш-очередью работают два процесса; в каждый момент времени семафор открывает доступ к очереди только для одного процесса. По тем же причинам и список свободных буферов нуждается в семафоре для защиты содержащейся в нем информации от искажения.
Рисунок 12.14. Выделение буфера с использованием семафоров На Рисунке 12.14 показана первая часть алгоритма getblk, реализованная в многопроцессорной системе с использованием семафоров. Просматривая буферный кеш в поисках указанного блока, ядро с помощью операции P захватывает семафор, принадлежащий хеш-очереди. Если над семафором уже кем-то произведена операция данного типа, текущий процесс приостанавливается до тех пор, пока процесс, захвативший семафор, не освободит его, выполнив операцию V. Когда текущий процесс получает право исключительного контроля над хеш-очередью, он приступает к поиску подходящего буфера. Предположим, что буфер находится в хеш-очереди. Ядро (процесс A) пытается захватить буфер, но если оно использует операцию P и если буфер уже захвачен, ядру придется приостановить свою работу, оставив хеш-очередь заблокированной и не допуская таким образом обращений к ней со стороны других процессов, даже если последние ведут поиск незахваченных буферов. Пусть вместо этого процесс A захватывает буфер, используя операцию CP; если операция завершается успешно, буфер становится открытым для процесса. Процесс A захватывает семафор, принадлежащий списку свободных буферов, выполняя операцию CP, поскольку семафор захватывается на непродолжительное время и, следовательно, приостанавливать свою работу, выполняя операцию P, процесс просто не имеет возможности. Ядро убирает буфер из списка свободных буферов, снимает блокировку со списка и с хеш-очереди и возвращает захваченный буфер. Предположим, что операция CP над буфером завершилась неудачно из-за того, что семафор, принадлежащий буферу, оказался захваченным. Процесс A освобождает семафор, связанный с хеш-очередью, и приостанавливается, пытаясь выполнить операцию P над семафором буфера. Операция P над семафором будет выполняться, несмотря на то, что операция CP уже потерпела неудачу. По завершении выполнения операции процесс A получает власть над буфером. Так как в оставшейся части алгоритма предполагается, что буфер и хеш-очередь захвачены, процесс A теперь пытается захватить хеш-очередь (*). Поскольку очередность захвата здесь (сначала семафор буфера, потом семафор очереди) обратна вышеуказанной очередности, над семафором выполняется операция CP. Если попытка захвата заканчивается неудачей, имеет место обычная обработка, требующаяся по ходу задачи. Но если захват удается, ядро не может быть уверено в том, что захвачен корректный буфер, поскольку содержимое буфера могло быть ранее изменено другим процессом, обнаружившим буфер в списке свободных буферов и захватившим на время его семафор. Процесс A, ожидая освобождения семафора, не имеет ни малейшего представления о том, является ли интересующий его буфер тем буфером, который ему нужен, и поэтому прежде всего он должен убедиться в правильности содержимого буфера; если проверка дает отрицательный результат, алгоритм запускается сначала. Если содержимое буфера корректно, процесс A завершает выполнение алгоритма.
Рисунок 12.15. Многопроцессорная версия алгоритма wait Оставшуюся часть алгоритма можно рассмотреть в качестве упражнения. Wait В многопроцессорной системе перед процессом встает задача не упустить при выполнении алгоритма wait потомка, прекратившего существование с помощью функции exit; если, например, в то время, пока на одном процессоре процесс-родитель запускает функцию wait, на другом процессоре его потомок завершил свою работу, родителю нет необходимости приостанавливать свое выполнение в ожидании завершения второго потомка. В каждой записи таблицы процессов имеется семафор, именуемый zombie_semaphore и имеющий в начале нулевое значение. Этот семафор используется при организации взаимодействия wait/exit (Рисунок 12.15). Когда потомок завершает работу, он выполняет над семафором своего родителя операцию V, выводя родителя из состояния приостанова, если тот перешел в него во время исполнения функции wait. Если потомок завершился раньше, чем родитель запустил функцию wait, этот факт будет обнаружен родителем, который тут же выйдет из состояния ожидания. Если оба процесса исполняют функции exit и wait параллельно, но потомок исполняет функцию exit уже после того, как родитель проверил его статус, операция V, выполненная потомком, воспрепятствует переходу родителя в состояние приостанова. В худшем случае процесс-родитель просто повторяет цикл лишний раз. Драйверы В многопроцессорной реализации вычислительной системы на базе компьютеров AT&T 3B20 семафоры в структуру загрузочного кода драйверов не включаются, а операции типа P и V выполняются в точках входа в каждый драйвер. Если для всех точек входа в драйвер использовать один и тот же семафор, но при этом для разных драйверов - разные семафоры, критический участок программы драйвера будет исполняться процессом монопольно. Семафоры могут назначаться как отдельному устройству, так и классам устройств. Так, например, отдельный семафор может быть связан и с отдельным физическим терминалом и со всеми терминалами сразу. В первом случае быстродействие системы выше, ибо процессы, обращающиеся к терминалу, не захватывают семафор, имеющий отношение к другим терминалам, как во втором случае. Драйверы некоторых устройств, однако, поддерживают внутреннюю связь с другими драйверами; в таких случаях использование одного семафора для класса устройств облегчает понимание задачи. В качестве альтернативы в вычислительной системе 3B20A предоставлена возможность такого конфигурирования отдельных устройств, при котором программы драйвера запускаются на точно указанных процессорах. Проблемы возникают тогда, когда драйвер прерывает работу системы и его семафор захвачен: программа обработки прерываний не может быть вызвана, так как иначе возникла бы угроза разрушения данных. С другой стороны, ядро не может оставить прерывание необработанным. Система 3B20A выстраивает прерывания в очередь и ждет момента освобождения семафора, когда вызов программы обработки прерываний не будет иметь опасные последствия. Фиктивные процессы Когда ядро выполняет переключение контекста в однопроцессорной системе, оно функционирует в контексте процесса, уступающего управление. Если в системе нет процессов, готовых к запуску, ядро переходит в состояние простоя в контексте процесса, выполнявшегося последним. Получив прерывание от таймера или других периферийных устройств, оно обрабатывает его в контексте того же процесса. В многопроцессорной системе ядро не может простаивать в контексте процесса, выполнявшегося последним. Посмотрим, что произойдет после того, как процесс, приостановивший свою работу на процессоре A, выйдет из состояния приостанова. Процесс в целом готов к запуску, но он запускается не сразу же по выходе из состояния приостанова, даже несмотря на то, что его контекст уже находится в распоряжении процессора A. Если этот процесс выбирается для запуска процессором B, последний переключается на его контекст и возобновляет его выполнение. Когда в результате прерывания процессор A выйдет из простоя, он будет продолжать свою работу в контексте процесса A до тех пор, пока не произведет переключение контекста. Таким образом, в течение короткого промежутка времени с одним и тем же адресным пространством (в частности, со стеком ядра) будут вести работу (и, что весьма вероятно, производить запись) сразу два процессора. Решение этой проблемы состоит в создании некоторого фиктивного процесса; когда процессор находится в состоянии простоя, ядро переключается на контекст фиктивного процесса, делая этот контекст текущим для бездействующего процессора. Контекст фиктивного процесса состоит только из стека ядра; этот процесс не является выполнимым и не выбирается для запуска. Поскольку каждый процессор простаивает в контексте своего собственного фиктивного процесса, навредить друг другу процессоры уже не могут. 15. Встроенные функции ОС. Встроенные команды ОС Вступление Как только человек научился выражать свои мысли в письменном виде, у него появилась потребность скрывать записанную информацию от любопытных глаз. Информация со временем менялась, от местоположения полянки на которой растут огромные грибы, до технической документации по новейшему истребителю-бомбардировщику, но требования по её защите оставались. Решались они разными путями, наиболее надёжным из которых считаются толстые двери и надёжные замки, подкреплённые охраной из здоровых и надёжных головорезов, вооружённых до зубов, которые следят друг за другом и окружающими, и понятия не имеющими что именно они охраняют. Для пущей гарантии, всё это можно подкрепить различными техническими устройствами, совершенство которых ограничивается только уровнем развития техники на тот момент, от арбалетов-самострелов и потайных рычагов и кнопок, до автоматических турелей с крупнокалиберными пулемётами и систем контроля основанных на биометрических параметрах. Однако, подобные меры доступны только богатым организациям, для охраны очень ценной информации. А что делать обычным людям, которые не готовы выкладывать дикие деньги за охрану своей информации, но, тем не менее, имеют что прятать от любопытных глаз. Единственный выход это сделать так, что если злоумышленник и сможет добыть интересующий его материал, исключить возможность для него им воспользоваться. В то же время, законный хозяин должен иметь возможность прочитать свои данные когда ему будет угодно. Один из методов, который может защитить данные без огромных затрат, это шифрование. В современном мире шифрование используется достаточно широко, и в самых различных видах, от примитивной перестановки букв в определённом порядке, чем иногда пользуются школьники передавая друг-другу "тайные" записки, до весьма изощрённых, используемых организациями посерьёзнее. С появлением Windows2000 Microsoft решил предоставить пользователям возможность достаточно серьёзного шифрования. Тот же алгоритм шифрования, практически без изменений, перекочевал и в Windows XP. Шифрование встроено в операционную систему, шифруется всё просто, работает очень быстро, но достаточно надёжно. В этом и кроются свои подводные камни, и иногда пользователи не понимающие того как это работает вместо того чтобы сохранить, безвозвратно теряют свои данные. Между тем, если немного позаботиться заранее, то можно полностью обезопасить себя от этого, и иметь возможность восстановить свои данные даже после полного краха системы. Функции шифрования доступны в Windows 2000 всех видов, и в Windows XP начиная с Professional. Windows XP Home Edition шифрование не поддерживает. Реализация шифрования одинакова, как в W2k так и в WinXP поэтому описание алгоритма по которому существляется шифрование подходит для обоих ОС. Но в XP изменилась системная политика по отношению к шифрованным файлам, с целью сделать шифрование более безопасным, поэтому процедур восстановления зашифрованных файлов в XP изменилась. Но, всё по порядку. Начнём с того что снаружи, о есть что видно пользователю. Что видит пользователь. Встроенные в ОС функции шифрования можно задействовать только на дисковых разделах отформатированных под NTFS. Другие файловые системы, доступные из под W2k/WinXP шифрование не поддерживают. Но если это условие соблюдено, то зашифровать что-нибудь элементарно. Для этого достаточно открыть Properties файла или папки (через правую кнопку мыши), нажимаем на кнопку Advanced, и в открывшемся окне ставим галочку в чекбоксе "Encrypt content to secure data". Два раза нажимаем на OK, в каждом из открытых окно, и дело сделано. Теперь, если открыть это же окно ещё раз, станет доступной кнопка Detail, нажав на которую можно увидеть ещё одно окно: С его помощью можно добавить, кто ещё из зарегистрированных на машине пользователей может пользоваться зашифрованным файлом (эта функция доступна только в WinXP, поэтому пользователям W2k искать её не стоит). Если пользователя которого вы хотите добавить нет в списке возможных, это значит что он не имеет соответствующего сертификата и ключа. Зашифруйте этим пользователем хоть один файл или папку, после чего попробуйте ещё раз, нужный пользователь должен появится. Разрешая другим пользователям пользоваться зашифрованными файлами не забывайте, что таким образом вы предоставляете ему тот же уровень контроля над шифрованием файла, который имеете сами. То есть, он получает возможность добавлять или удалять пользователей, которые имеют доступ к файлу, а при желании сможет расшифровать файл (для чего требуется просто снять галочку в чекбоксе Encrypt content to secure data). Если после этого он зашифрует его заново, из под своей учётной записи, то вы потеряете доступ к собственному файлу. Ещё в этом окне показывается имя "Encrypted Data Recovery Agent" который, в случае чего, сможет восстановить файл. Но, я несколько забегаю вперёд. Для пользователей которым не хватает возможностей по управлению функциями шифрования, предоставляемых Windows Explorer, есть утилитка для командной строки, под названием "cipher". Справку по этой команде можно получить набрав в командной строке cipher /?. Для пользователя имеющего все права для доступа к зашифрованному файлу работа с ним абсолютно прозрачна, и ничем не отличается от работы с любым другим файлом, расшифровка и шифрование производятся на лету. Но если содержимое зашифрованного файла попытается прочитать пользователь не имеющий на это право, то всё что он увидит это сообщение о том, что в доступе к файлу отказано. Однако, не стоит обманывать себя, пользователь будет иметь такой доступ к файлу, какой ему предоставит файловая система, поэтому если вы не позаботитесь о том, что бы выставить соответствующие разрешения на доступ средствами NTFS, то у пользователя будет возможность манипулировать вашим файлом. То есть, он не сможет прочитать его содержимое, но сможет его переименовать, переместить, или просто стереть. Хотя не всё так просто. Даже владелец файла, который имеет полные права на пользование файлом, при работе с зашифрованными данными вынужден подчинятся некоторым ограничениям. Ограничений всего два, но в сочетании они дают достаточно много других вариантов. Первое, что стоит помнить при работе с зашифрованными файлами, это что хранится они могут только на NTFS разделах. Второе, это что файл может быть либо зашифрован, либо сжат средствами файловой системы, но не то и другое одновременно. Кроме этих двух ограничений, надо помнить пару правил: любой файл попавший в зашифрованную папку автоматически шифруется, и таким остаётся, даже после того как покинет эту папку. Второе правило гласит, что атрибут шифрования имеет больший приоритет, чем атрибут сжатия. Таким образом получается, что копируя зашифрованный файл с NTFS раздела куда-либо ещё, файл расшифровывается. Если пользователь не может расшифровать файл, то он не сможет и скопировать его на не-NTFS раздел, даже если у него есть полные права доступа к файлу, и он может делать с ним что угодно на NTFS разделе. Кроме этого, из этих правил и ограничений следует, что если скопировать сжатый файл в зашифрованную папку, он автоматически декомпрессируется и зашифруется. В то же время, если скопировать зашифрованный файл в сжатую папку, то он останется неизменным, не сжатым, но зашифрованным. Если поместить незашифрованный файл в зашифрованную папку, то файл автоматически зашифруется, и останется зашифрованным даже в том случае, если его переместить из зашифрованный папки куда-либо ещё. В общем, помня об этих правилах можно точно предсказать, что случится с сжатым или зашифрованным файлом если произвести с ним то или иное действие. Не смотря на простоту таких правил, достаточно часто можно встретить непонимание этих моментов, когда речь заходит о чуть более сложных примерах. Поэтому рассмотрим ещё один пример. Если пользователь А зашифрует папку, а пользователь В поместит в неё свой файл, то файл автоматически зашифруется. Но зашифруется с ключом пользователя В, который поместил файл в папку, а не с ключом пользователя А, зашифровавшего папку. Пользователь A сможет переименовать или переместить этот файл, но он не сможет прочитать или расшифровать его. Он не сможет сделать копию с этого файла, так как при этом система попытается зашифровать файл с ключом пользователя А, что не удаться, потому что файл уже зашифрован с ключом пользователя В, и его надо сначала расшифровать. Пользователь В, в свою очередь, не сможет снять атрибут Encrypted со всей папки, потому что зашифрована она с ключом пользователя А, но он сможет снять такой атрибут со своего файла, который лежит в этой папке, и оставить не зашифрованный файл в зашифрованной папке. Если после этого кто-нибудь из пользователей (А, С, не важно) сделает копию с этого файла внутри этой папки, то копия файла автоматически зашифруется с ключом этого пользователя. И, наконец, пользователь А может в любой момент снять атрибут Encrypted с папки зашифрованой с его ключом, но это не окажет никакого влияния на находящиеся в папке файлы, как зашифрованные пользователем А, так и кем-либо другим. Если добавить в этот пример возможность для пользователей XP разрешать любому другому пользователю, по выбору, пользоваться своими шифрованными файлами, то всё становится ещё запутаннее. Впрочем, я надеюсь, что приведённых выше примеров и объяснений хватит для того, что бы читатель мог абсолютно чётко прогнозировать, что случится с его файлами при использовании тех или иных функций шифрования в W2k/WinXP. Остаётся дать несколько советов, которые помогут использовать шифрование более эффективно. Наиболее часто встречающаяся ошибка, которую совершают пользователи желающие защитить свои файлы, это шифрование всего одного файла который, собственно, и защищается. Однако, зачастую этого недостаточно. В процессе работы ваши файлы вполне могут оказаться и в других местах, таких как TEMP или TMP папки. Кроме этого, некоторые программы (например Microsoft Office) при работе делают временные копии файлов с которыми работают в той же директории, где находится и оригинальный файл. Задумано это с благой целью, в случае с Microsoft Office, например, эти копии используются для восстановления файлов случае сбоя. Но эти копии не шифруются автоматически, поэтому ваши документы вполне могут оказаться прочитанными не теми, кем вам хотелось бы. Что бы этого не случилось, я советую вам шифровать не отдельные файлы, а директории где они хранятся. Кроме этого, не забудьте зашифровать и TEMP папку. Этим вы обезопасите себя, и если какие-либо временные файлы или копии ваших данных или документов будут создаваться, они будут автоматически зашифрованы. Это что касается внешней стороны, видимой для пользователя. Но для полного понимания всех потенциальных проблем, которые могут возникнуть при использовании шифрования в W2k/WinXP, что бы знать чего стоит и чего не стоит ожидать от шифрования, не обойтись без того, что бы рассмотреть как работает шифрование "изнутри". Эта информация необходима и для того, что бы знать как решать проблемы возникающие с шифрованием. Наиболее часто встречающейся из которых является потеря информации в результате техногенных "катаклизмов", от которых не гарантирован ни один компьютер, или в результате ошибок пользователя, от которых не гарантирован ни один из читателей. |