Добавлен: 29.10.2018
Просмотров: 47980
Скачиваний: 190
1056
Глава 11. Изучение конкретных примеров: Windows 8
Почему это плохо? Насколько ответ зависит от времени удержания блокировки,
длины кванта, а также от того, является ли система многопроцессорной?
30. Для поддержки POSIX исходная API-функция NtCreateProcess поддерживает
дублирование процесса, чтобы обеспечить поддержку функции fork. В UNIX за
функцией fork в большинстве случаев практически сразу же следует функция
exec. Одним из примеров, где это используется исторически, была разработанная
в Berkeley программа dump(8S), предназначавшаяся для создания резервной ко-
пии дисков на магнитной ленте. Функция fork использовалась в качестве способа
установки контрольных точек в программе dump, чтобы ее можно было повторно
запустить при ошибке накопителя на магнитной ленте. Приведите пример того,
как Windows сможет сделать то же самое с помощью NtCreateProcess.
Подсказка
: рассмотрите процессы, в которых запущены DLL-библиотеки для
реализации функций, предоставляемых сторонними разработчиками.
31. Файл имеет следующее отображение.
Смещение
0
1
2
3
4
5
6
7
8
9
10
Дисковый адрес
50
51
52
22
24
25
26
53
54
–
60
Определите элементы MFT для участков.
32. Возьмем запись MFT из рис. 11.25. Предположим, что файл рос и в конце файла
был выделен десятый блок. Номер этого блока 66. Как теперь будет выглядеть
запись MFT?
33. На
рис. 11.28, б первые два участка имеют длину по 8 блоков каждый. Случайно ли
они имеют равную длину или это вызвано способом работы сжатия? Объясните
ответ.
34. Предположим, что вы хотите создать Windows Vista Lite. Какие поля, изображен-
ные на рис. 11.29, можно убрать без ослабления безопасности системы?
35. Стратегия смягчения последствий, применяемая для повышения безопасности,
несмотря на наличие уязвимостей оказалась вполне удачной. Современные ата-
ки отличаются высокой изощренностью, и для создания надежно работающего
вредоносного кода зачастую требуется наличие нескольких уязвимостей. Одной
из обычно востребуемых уязвимостей является утечка информации. Объясните,
как такая утечка может использоваться для обхода рандомизации адресного про-
странства при атаке на основе возвратно-ориентированного программирования.
36. Используемая многими программами (веб-браузеры, Office, СОМ-серверы) мо-
дель расширения состоит в том, чтобы разместить DLL, которые перехватывают
и расширяют базовую функциональность. Хороша ли эта модель для службы на
основе RPC, если она олицетворяет клиентов до загрузки DLL? Почему нет?
37. Когда при работе на компьютере с архитектурой NUMA диспетчеру памяти
Windows нужно выделить физическую страницу для обработки страничной
ошибки, то он пытается использовать страницу из узла NUMA идеального про-
цессора для текущего потока. Почему? Что будет, если поток выполняется на
другом процессоре?
38. Приведите пару примеров, когда приложение может легко восстановиться из
резервной копии на основе теневой копии тома.
Вопросы
1057
39. В разделе 11.10 обеспечение новой памяти для кучи процесса было упомянуто
как один из тех случаев, когда требуется подача обнуленных страниц (чтобы вы-
полнить требования по безопасности). Дайте один или несколько дополнительных
примеров таких операций с виртуальной памятью, которые требуют обнуленных
страниц.
40. Windows содержит гипервизор, позволяющий нескольким операционным систе-
мам работать одновременно. Эта функция доступна клиентам, но ярче всего она
проявляется в облачных вычислениях. Когда к гостевой операционной системе
применяется обновление системы безопасности, это практически ничем не от-
личается от установки исправлений. Но когда обновление системы безопасности
применяется к основной операционной системе, для пользователей облачных
вычислений это может превратиться в большую проблему. Каков характер этой
проблемы? Что тут можно предпринять?
41. Команда regedit может использоваться для экспортирования части (или всего)
реестра в текстовый файл во всех текущих версиях Windows. Сохраните реестр
несколько раз в течение рабочего сеанса и посмотрите, что изменилось. Если у вас
есть доступ к компьютеру, на котором вы можете инсталлировать программное
или аппаратное обеспечение, — найдите те изменения, которые происходят при
добавлении или удалении программы или устройства.
42. Напишите программу для UNIX, которая имитирует запись в NTFS файла с не-
сколькими потоками. Она должна принимать в качестве аргументов список из
одного или нескольких файлов и записывать выходной файл, который содержит
один поток с атрибутами всех аргументов и дополнительные потоки с содержимым
каждого аргумента. Затем напишите вторую программу для отчета по атрибутам
и потокам и извлечения всех компонентов.
Гл а в а 12
.
Разработка операционных систем
В предшествующих одиннадцати главах мы рассмотрели большое количество ма-
териала и познакомились с множеством понятий и примеров, имеющих отношение
к операционным системам. Однако задача изучения известных операционных систем
сильно отличается от задачи разработки новой. В этой главе мы собираемся обсудить
несколько вопросов, которые должны учитывать разработчики новых операционных
систем.
В среде разработчиков операционных систем ходит множество изустных преданий
о том, что такое хорошо и что такое плохо, однако на удивление мало этих историй
записано. Наиболее важной книгой можно назвать классический труд Фреда Брукса
(Brooks, 1975), в котором автор делится своим опытом проектирования и реализации
операционной системы IBM OS/360. Материал выпущенного к 20-летней годовщине
издания был пересмотрен, к тому же в книгу было включено несколько новых глав
(Brooks, 1995).
Тремя классическими трудами по проектированию операционных систем являются
книги Lampson (1984), Corbato (1991), Saltzer et al. (1984). Как и книги Брукса, эти
три издания успешно пережили время, прошедшее с момента их написания. Большая
часть рассматриваемых в них вопросов сохранила свою актуальность и в наши дни.
Данная глава основана на содержимом этих источников, кроме того, в ней используется
личный опыт участия автора в проектировании двух систем: Amoeba (Tanenbaum et
al., 1990) и MINIX (Tanenbaum and Woodhull, 2006). Поскольку среди разработчиков
операционных систем нет единого мнения по вопросу о том, как лучше всего проекти-
ровать операционные системы, эта глава будет носить более личный характер, более
умозрительный и, несомненно, более противоречивый, чем предыдущие.
12.1. Природа проблемы проектирования
Разработка операционных систем представляет собой в большей мере инженерный
проект, нежели точную науку. В этой области значительно труднее наметить ясные
цели и достичь их. Рассмотрим для начала вопрос постановки задачи.
12.1.1. Цели
Чтобы проект операционной системы был успешным, разработчики должны иметь
четкое представление о том, чего они хотят. При отсутствии цели очень трудно при-
нимать последующие решения. Чтобы этот вопрос стал понятнее, полезно взглянуть на
два языка программирования, PL/1 и C. Язык PL/1 был разработан корпорацией IBM
в 1960-е годы, так как поддерживать одновременно FORTRAN и COBOL и слышать
12.1. Природа проблемы проектирования
1059
при этом за спиной ворчание ученых о том, что Algol лучше, чем FORTRAN и COBOL
вместе взятые, было невыносимо. Поэтому был образован комитет для создания ново-
го языка, удовлетворяющего запросам всех программистов: PL/1. Этот язык обладал
некоторыми чертами языка FORTRAN, некоторыми особенностями языка COBOL
и некоторыми свойствами языка Algol. Проект потерпел неудачу, потому что ему недо-
ставало единой концепции. Проект представлял собой набор свойств, конфликтующих
друг с другом, к тому же язык PL/1 был слишком громоздким и неуклюжим, чтобы
программы на нем можно было эффективно компилировать.
Теперь взглянем на язык C. Он был спроектирован всего одним человеком, Деннисом
Ритчи, для единственной цели — системного программирования. Успех его был ко-
лоссален, и это не в последнюю очередь объяснялось тем, что Ритчи знал, чего хотел,
а чего не хотел. В результате спустя десятилетия после своего появления этот язык все
еще широко распространен. Наличие четкого представления о своих целях является
решающим.
Чего же хотят разработчики операционных систем? Очевидно, ответ варьируется от
системы к системе и будет разным для встроенных и серверных систем. Для универ-
сальных операционных систем основными являются следующие четыре пункта:
1. Определение абстракций.
2. Предоставление примитивных операций.
3. Обеспечение изоляции.
4. Управление аппаратурой.
Далее будет рассмотрен каждый из этих пунктов.
Наиболее важная, но, вероятно, наиболее сложная задача операционной системы за-
ключается в определении правильных абстракций. Некоторые из них, такие как про-
цессы и файлы, используются уже так давно, что могут показаться очевидными. Другие,
такие как потоки исполнения, представляют собой более новые и потому не столь
устоявшиеся понятия. Например, если состоящий из нескольких потоков процесс,
один из потоков которого блокирован вводом с клавиатуры, клонируется, то должен
ли поток в новом процессе также ожидать ввода с клавиатуры? Другие абстракции
относятся к синхронизации, сигналам, модели памяти, моделированию ввода-вывода
и иным областям.
Каждая абстракция может быть реализована в виде конкретных структур данных.
Пользователи могут создавать процессы, файлы, каналы и т. д. Управляют этими
структурами данных при помощи примитивных операций. Например, пользователи
могут читать и писать файлы. Примитивные операции реализуются в виде системных
вызовов. С точки зрения пользователя, сердце операционной системы формируется
абстракциями, а операции над ними возможны при помощи системных вызовов.
Поскольку на одном компьютере могут одновременно зарегистрироваться несколько
пользователей, операционная система должна предоставлять механизмы для отделения
их друг от друга. Один пользователь не должен вмешиваться в работу другого. Концеп-
ция процессов широко используется для группирования ресурсов с целью их защиты.
Как правило, защищаются файлы и другие структуры данных. Еще одним местом, где
разделение играет весьма важную роль, является виртуализация: гипервизор должен
обеспечить обособленность виртуальных машин от всех сложностей работы других
виртуальных машин. Ключевая цель проектирования операционной системы заклю-
1060
Глава 12. Разработка операционных систем
чается в том, чтобы гарантировать, что каждый пользователь может выполнять только
разрешенные ему действия с данными, к которым у него есть право доступа. Однако
пользователям бывает необходимо совместное использование данных и ресурсов,
поэтому изоляция должна быть избирательной и контролироваться пользователями.
Все это существенно усложняет устройство операционной системы. Почтовые про-
граммы не должны наносить вред веб-браузерам. Даже если существует только один
пользователь, разные процессы должны быть разделены. Чтобы защитить процессы
друг от друга, на некоторых системах, таких как Android, каждый процесс, принадле-
жащий одному и тому же пользователю, будет запускаться с иным пользовательским
идентификатором.
С этим вопросом тесно связана проблема изолирования отказов. Если какая-либо часть
системы выйдет из строя (чаще всего это один из пользовательских процессов), то
сбойный процесс не должен нарушить работу всей операционной системы. Устройство
операционной системы должно гарантировать изоляцию различных частей операци-
онной системы друг от друга, чтобы их сбои были независимыми. Заходя еще дальше,
можно задаться вопросом: а не должна ли операционная система быть устойчивой
к сбоям и самоисцеляющейся?
Наконец, операционная система должна управлять аппаратурой. В частности, она
должна заботиться обо всех низкоуровневых микросхемах, таких как контроллеры
прерываний и контроллеры шин. Она также должна обеспечивать каркас для того,
чтобы драйверы устройств могли управлять крупными устройствами ввода-вывода,
такими как диски, принтеры и дисплей.
12.1.2. Почему так сложно спроектировать
операционную систему?
Закон Мура гласит, что аппаратное обеспечение компьютера увеличивает свою произ-
водительность в 100 раз каждые 10 лет. Никто, к сожалению, так и не сформулировал
ничего подобного для программного обеспечения. Никто не говорит даже, что операци-
онные системы вообще совершенствуются с годами. В самом деле, можно утверждать,
что часть из них в некоторых аспектах (таких, как надежность) стали даже хуже, чем,
например, операционная система UNIX Version 7 образца 1970-х годов.
Почему? Как правило, основными причинами оказываются инерция и желание со-
хранить обратную совместимость, хотя неумение разработчиков придерживаться
принципов хорошего проектирования тоже вносит свою лепту. Но этот вопрос следует
обсудить подробнее. Операционные системы принципиально отличаются от небольших
прикладных программ, которые можно загрузить за 49 долларов. Рассмотрим восемь
аспектов, благодаря которым разработка операционной системы оказывается значи-
тельно сложнее написания прикладной программы.
Во-первых, операционные системы стали крайне громоздкими программами. Никто
в одиночку не может за несколько месяцев написать операционную систему. Или даже
за несколько лет. Все современные версии UNIX содержат миллионы строк кода; объ-
ем Linux, к примеру, достигает 15 млн. В Windows 8, наверное, от 50 до 100 млн строк
кода, в зависимости от того, что брать в расчет (у Vista было 70 млн, но это количество
изменялось, поскольку код как добавлялся, так и удалялся). Ни один человек на Земле
не способен понять миллион строк, не говоря уже о 50 или 100 млн. Если вы создаете