Windows NT/2000/XP

Наработки Microsoft no OS/2 New Technology были в 1993 г. выпущены на     рынок под названием Windows NT. Версии 3.x и 4.0 этой системы обеспечивали совместимость с 16-разрядными приложениями для OS/2 1.x в отдельной подсистеме, без возможности обращаться из 16-разрядных приложений к 32-разрядным DLL и наоборот.

В описываемый период из DEC в Microsoft в полном составе перешла команда     разработчиков ядра VMS под управлением Д. Катлера. Microsoft широко рекламировал этот факт и утверждал, что Windows NT находится с VMS в гораздо более близком родстве, чем с OS/2 1.x. Из табл. видно что это утверждение не очень-то согласуется с действительностью.

	OS/2 1.x	Windows NT 3.x	VMS
Многозадачность	Вытесняющая	Вытесняющая	Вытесняющая
Ядро	Монолитное	Монолитное	Монолитное
Ввод-вывод	Асинхронный	Асинхронный	Асинхронный
Защита памяти	Сегментная	Страничная	Страничная
Количество уровней	Трехуровневая	Двухуровневая	Трехуровневая
Сборка при загрузке	Динамическая	Динамическая	Статическая
Подкачка	Задачная	Страничная	Страничная
Поиск жертвы		FIFO	FIFO
Файловая система	Без транзакций	Журнальная	Журнальная
Программный RAID	RAID 1	RAID 0 1 5	RAID 0 1
Длина имени файла			32+16
Версии файлов	Нет	Нет	Да
Форматы файлов	Потоковый	Потоковый	Блочный, Относительный, Индексно-последовательный
Командный процессор	cmd.exe	cmd.exe	DCL
Граф, подсистема	РМ	Win32	X Window
Ид. пользователя	Вся система	Задача	Задача
БД учетных записей	Распределенная	Распределенная	Локальная
Сетевой протокол	NETBIOS/SMB	NETBIOS/SMB	DECNet

Сравнение OS/2 1.2, Windows NT и VMS

Наиболее важные заимствования из VMS страничная подкачка и идентификация     пользователя на уровне процессов являлись ответом на насущные требования развития системы и могли быть заимствованы из любой ОС, адекватной времени. В остальном, табл. П.1 показывает, что OS/2 1.x, безусловно, приходится Windows NT гораздо более близкой родней, чем VMS.

Наиболее важной заимствованной концепцией была журнальная файловая     система NTFS, представляющая собой любопытный гибрид HPFS (основной ФС OS/2) и FCS2 (основной ФС VAX/VMS). Это заимствование следует признать довольно удачным.

Гораздо менее удачным было заимствование своеобразной стратегии     управления рабочими множествами процессов в ОЗУ, используемой в VMS: разработчики Microsoft устранили из этой стратегии одно из ключевых понятий, квоту размера рабочего множества. В результате получилась система, практически не способная воспользоваться преимуществами страничной подкачки, потому что даже небольшая нехватка оперативной памяти приводит к резкому падению производительности из-за неспособности системы сбалансировать потребности приложений и дискового кэша.

Еще одна ключевая для понимания архитектуры Win32 концепция была     позаимствована вовсе не из VMS и даже не из OS/2 1.x, а была, скорее всего, введена по настоятельным просьбам разработчиков графических приложений для Apple Macintosh. Речь идет о системном реестре (system registry), централизованной базе данных, в которой все модули системы, стандартные утилиты и прикладные программы хранят все, что считают нужным сохранить.

Системный реестр впервые был реализован в Mac OS. Эта система имеет     довольно простое ядро и небогатый набор системных настроек, поэтому реестр Mac OS в основном содержит настройки прикладных программ и в такой форме вполне терпим. Напротив, довольно сложная многопользовательская Windows NT, поддерживающая широкий спектр внешних устройств, нуждается в большом объеме конфигурационных данных для самой системы. Характер обращений к разным частям этих данных сильно различается некоторые, например, нужны только при загрузке системы, а изменению подлежат только при изменении аппаратной конфигурации. Другие же меняются при каждом открытии нового окна пользовательской программой. Относительная ценность этих данных также различается очень резко: искажение некоторых может привести к невозможности загрузить систему или к потере пользователями доступа к ней, некоторые другие можно было бы и не хранить вовсе. В свете этого, идея общей "свалки", в которой содержится все на свете, начиная от слов, которые произносил пользователь, пытаясь убрать с экрана знаменитую скрепку, и заканчивая БД учетных записей представляется автору не очень-то здравой мыслью.

В Windows NT этот концептуальный недостаток усугубляется недостатками     реализации реестр не имеет адекватных средств резервного копирования и восстановления (при фатальных повреждениях реестра Microsoft рекомендует переустановку системы) и фактически лишен средств самоконтроля и диагностики. Во всяком случае, в версии 4.0 (автор не имел случая проверить это на более поздних версиях системы, но судя по тому, что исправление этой ошибки не анонсировалось, в 2000/ХР ситуация не изменилась. ОС никогда не уменьшала объем реестра, даже после удаления большого количества ключей.

Еще одним важным новшеством была поддержка нескольких процессоров кроме     х8б первые версии Windows NT были реализованы для RISC процессоров MIPS и DEC Alpha, и, существенно позднее, для PowerPC Большинство RISC-процессоров не имеют многоуровневых режимов доступа, характерных для VAX и 80286/х8б, поэтому разработчики Windows NT были вынуждены отказаться от привилегированных разделяемых библиотек (понятие, которое в той или иной форме присутствовало как в OS/2 1.x, та и в VAX/VMS) и перейти к двухуровневой системе привилегий.

Разработчики приложений не проявили интереса к альтернативным аппаратным     архитектурам, поэтому NT на этих архитектурах не имела большого успеха, и в 1999 г. без большого шума была прекращена поддержка Windows NT для последнего неинтеловского процессора, который к тому времени уже назывался Compaq Alpha [techupdate.zdnet.com].

В отличие от Unix, система не могла быть перенесена на процессоры с     порядком байт, отличным от х86, из-за того, что в коде системы и флагманских приложений широко использовались неявные предположения о порядке байт (преобразование указателей на short в указатели на long и т. д.). К тому же, перенос на 64-разрядные процессоры оказался сопряжен с неожиданной сложностью: дело в том, что очень многие системные вызовы и документированные структуры данных Win32 используют описатели целочисленных значений, явно указывающие на количество байт в значении, такие, как WORD (два байта) или DWORD (четыре байта). В результате, изменение размера некоторых скалярных значений на восьмибайтовые потребовало бы переделки спецификаций системных вызовов и переработки исходных текстов программ, использующих такие вызовы.

Для сравнения, в Unix везде, где это возможно, используются непрозрачные     типы (off_t для длины файла и смещения в нем, size_t для размера структуры данных в памяти, pid_t для идентификатора пользователя), размер которых в байтах явно не указан. Так, на 32-разрядных архитектурах size_t имеет размер 32 бита, а на 64-разрядных 64. Чтобы написать программу, не переносимую между 32- и 64-разрядными системами семейства Unix, программисту надо предпринимать специальные усилия, нарушающие все правила хорошего тона программирования. Поэтому системы семейства UNIX давно перенесены на 64-разрядные микропроцессоры и используют их потенциал полностью, а о проекте Win64 к моменту написания книги было известно лишь, что где-то глубоко в недрах Microsoft существует условно работоспособный прототип.

С момента выхода версии 3.51 и до времени написания книги архитектура     системы не подвергалась ни пересмотру, ни сколько-нибудь существенному развитию [Андреев/Беззубов]. Наибольшее количество новшеств было введено в Windows 2000, когда в состав системы была включена служба каталогов Active Directory и ряд мелких улучшений. В частности, было исправлено множество мелких, но раздражающих недостатков стека TCP/IP версии 4.0, такие, как невозможность сбросить кэш запросов DNS без перезагрузки системы или присвоить интерфейсу дополнительный адрес без сброса всех TCP соединений на основном адресе того же интерфейса. В Windows XP были введены средства импорта реестра систем линии Windows 95/98/ME, сокеты типа RAW (до этого низкоуровневые утилиты TCP/IP, такие, как ping и tracert, были вынуждены работать непосредственно с драйвером сетевого интерфейса и самостоятельно формировать заголовки пакетов IP) и новая схема защиты от неавторизованного копирования (к моменту написания книги опыт эксплуатации этой схемы слишком мал, чтобы можно было делать обоснованные выводы об ее удобстве для пользователя и надежности) [Ахметов 2001].

При весьма слабо изменяющемся ядре, развивался преимущественно     пользовательский интерфейс. Версии 3.x вместо стандартного к тому времени рабочего стола использовали архаичный Program Manager, аналогичный использовавшемуся в Windows 3.x В версии 4.0 система получила desktop (рабочий стол), аналогичный Windows 95. В ХР все управляющие элементы графического интерфейса подверглись полному перепроектированию и были перекрашены в жуткий ядовито-голубой цвет.

В первые годы после ветвления проекта OS/2 на IBM OS/2 и Windows NT     реакция пользователей свидетельствовала о том, что решение IBM было более адекватно их потребностям оценки пользовательской базы IBM OS/2 и Windows NT сравнялись только в 1997/1998 гг. Потребовались выход Windows 95 и титанические усилия по перетягиванию пользователей на приложения для Win32 (так, при разработке Office 95 Microsoft пошел на беспрецедентный шаг и сделал пакет совместимым по формату файлов с предыдущей версией Office), чтобы к 1999/2000 гг. Windows NT и ее новые версии, Windows 2000/XP стали приемлемым решением для настольных персональных компьютеров. Потребовался также провал проекта OS/2 for PPC, чтобы устранить конкуренцию со стороны ближайшего родственника, претендовавшего (и не без успеха) на ту же рыночную нишу. Тем не менее, до сих пор успехи системы на рынке ОС для настольных компьютеров следует охарактеризовать как скромные.

Успехи системы на серверном рынке были более внушительными. Главными     недостатками Windows NT в качестве сервера являлись (и до сих пор являются) неэффективная стратегия управления памятью и беспрецедентное для промышленно эксплуатируемого программного продукта количество проблем с безопасностью. Автор не имеет достоверных сведений на этот счет, но складывается впечатление, что Microsoft тестирует свои продукты только на отсутствие ошибок, от которых программа прекращает работать сама, но не делает даже попыток искать ошибки, используя которые можно целенаправленно нарушить работу системы или получить к ней неавторизованный доступ.

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

Второй недостаток является критически важным и одного его в идеальном     мире было бы достаточно, чтобы Windows NT не использовалась в качестве сервера ни при каких обстоятельствах. Однако давление управленческого персонала во многих организациях было очень сильным, поэтому система получала распространение. Чаще всего ее использовали в локальных сетях, не подключенных к Internet вообще или закрытых от глобально сети брандмауэром, что несколько снижало требования к безопасности.

К тому же, пока NT была малоиспользуемой системой с бедным набором     сетевых сервисов, мало кто всерьез интересовался ее взломом. Это привело к усилению давления со стороны управленцев "вот видите, у соседей стоит и ничего", поэтому серверы под управлением NT все чаще и чаще подключались к Internet, иногда даже без закрытия каким-либо брандмауэром (надо отметить, что firewall (брандмауэр) в данном случае мало чем может помочь сайт [www.microsoft.com] закрыт маршрутизатором с фильтрацией пакетов "по самые уши", и то его "роняют" несколько раз в год). Распространение системы привело к тому, что взломщики из спортивного интереса заинтересовались ею всерьез.

Первой ласточкой был выпущенный в 1997 г. свободно распространяемый     продукт Back Orifice (дословно "задний проход"), демонстрировавший целый набор способов получения неавторизованного доступа (в том числе и с последующей установкой троянских программ) к системам Win32. Устанавливаемый в качестве троянской программы компонент пакета долгое время был лучшим из доступных инструментов удаленного управления Win32-системами и автор знает немало системных администраторов, которые использовали его в своих сетях [www.sourceforge.net bo2k].

Впрочем, одна ласточка весны не делает, и еще три года пользователи     Win32-систем жили относительно спокойно (если можно считать спокойной жизнью постоянную борьбу с макровирусами для MS Office, почтовыми вирусами и другими порождениями больной фантазии). За это время в систему добавились новые сетевые сервисы и расширилась номенклатура сервисов, запускаемых при установке ОС по умолчанию например, в их число попал флагманский серверный продукт, сервер ftp/HTTP и ряд других протоколов, IIS (Internet Information Server).

Собственно весна настала в августе 2001 г. с пандемией сетевого червя     Code Red, который, как и червь Морриса, использовал несколько каналов распространения, в том числе срывы буфера в сетевых сервисах IIS. Как и червь Морриса, заразив одну из машин домена, Code Red распространялся на другие машины того же домена простым копированием по сети. Дальнейшее развитие событий, впрочем, резко отличалось от последствий атаки червя Морриса: Microsoft довольно быстро выпустила заплаты (patches), исправлявшие часть используемых вирусом ошибок однако полное количество ошибок, оставшихся в коде системы и сетевых сервисов, от этого почти не изменилось. Атаки червей и поливалентных (использующих несколько каналов распространения) вирусов, которые легко преодолевают корпоративные брандмауэры (firewalls), продолжались на протяжении всего 2001 г., демонстрируя все новые и новые проблемы в системе безопасности Windows NT/2000/XP.

В опубликованном в сентябре 2001 г. докладе аналитическая компания     Gartner Group рекомендовала ни при каких обстоятельствах не использовать IIS из-за огромного количества известных и весьма пессимистических прогнозов на количество неизвестных уязвимостей.

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

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

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

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

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

Дата добавления: 2015-07-12