Cколько стоит упасть и отжаться: вероятность тотального краха

ВАЖНЕЙШАЯ ХАРАКТЕРИСТИКА ОПЕРАЦИОННОЙ СИСТЕМЫ — ЕЕ НАДЕЖНОСТЬ (В КОНТЕКСТЕ УСТОЙЧИВОСТИ К СБОЯМ) И СРЕДНЕЕ ВРЕМЯ «РЕГЕНЕРАЦИИ» ПОСЛЕ ПАДЕНИЙ. ДАВАЙТЕ СРАВНИМ, НАСКОЛЬКО УСТОЙЧИВА WINDOWS И КОНКУРИРУЮЩАЯ С НЕЙ LINUX И ПОЧЕТНЫЙ КЛАН XBSD.

Постановка задачи

«Уронить» можно любую операционную систему. Как говориться, против лома нет приема, а против дураков — тем более. Поэтому условимся сразу, что никаких зверских действий мы совершать не будем, ведь это не тест на выносливость и не олимпийские соревнования, а обычная жизнь со всеми ее пагубными факторами, в число которых входят: сбои питания, отказы аппаратуры, «корявое» программное обеспечение и глюки самой системы. Вирусы и хакерские атаки не упомянуты по той простой причине, что защищенность системы определяется прежде всего принятой политикой безопасности, а отнюдь не ее архитектурой. Программа, запущенная из под root'а, сотворит с Linux'ом/xBSD что угодно. И хотя у xBSD существует возможность существенно затруднить внедрение rook-kit'ов (чего не может сделать Windows), это ничего не меняет: у злоумышленника остается достаточно полномочий для нанесения непоправимого вреда.

Мы будем сравнивать только должным образом «заштопанные» и правильно сконфигурированные системы, исходя из предположения, что администратор не дурак и предпринимает все возможное для предотвращения сбоев: имеет RAID, UPS, регулярно резервирует данные, а перед установкой программ проверяет их самой свежей версией антивируса.

Программа раз, программа два…

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

Немногие Windows-программы устанавливаются путем прямого копирования каталога с файлами в нужную директорию (распаковки архива). В подавляющем большинстве случаев они снабжаются инсталлятором, который представляет собой двоичный файл. Именно инсталлятор производит непредсказуемые действия: копирует новые системные библиотеки (или замещает старые), регистрирует OLE/DCOM/ActiveX компоненты в реестре и делает еще много других не восстанавливаемых при деинсталляции гадких вещей. Поэтому установка новой программы под Windows – это всегда риск, и после традиционного предложения перезагрузиться, выдаваемого инсталлятором, система может вообще перестать запускаться, работать нестабильно и так далее.

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

Также существует целый легион утилит автоматической деинсталляции, создающих «слепок» файловой системы вместе с реестром до начала установки программы и определяющих, какие изменения произвел инсталлятор. К сожалению, они не в состоянии восстанавливать замещенные версии библиотек и, будучи по своей природе GUI-приложениями, работают только при полностью загруженной системе, а если система не загружается — что тогда? Правильно, тогда ласты!

Вообще-то, Windows содержит встроенную утилиту MS Backup, позволяющую резервировать реестр и «жизненно важные» системные компоненты. Однако возможности MS Backup более чем ограничены и спасают далеко не всегда. Так что установка программ под Windows – это русская рулетка, только в барабане заряжены все шесть патронов. Установив внешне безобидную программку, можно потратить целый день (а то и два), выковыривая ее из системы.

В Windows Vista с большим опозданием появилась «песочница» (sandbox), позволяющая устанавливать программы в псевдовиртуальной машине, предотвращая тем самым пагубное воздействие инсталляторов на основную систему. Но при ближайшем рассмотрении выясняется, что все сводится к виртуализации некоторых ветвей реестра и системной папки, а, например, IE tootlbar никак не защищен, и вместе с ним не защищено и многое другое...

В этом отношении Linux/xBSD ведут себя совершенно иначе. Лишь немногие программы требуют принудительной инсталляции. Остальные же устанавливаются вполне традиционным путем через «./configure && make make install».

Самое главное — в Linux/xBSD существует (и широко используется) легальная установка любой программы в домашний каталог пользователя (вместе со всеми системными библиотеками, которые она тянет за собой). При этом никакого воздействия на «общесистемные» библиотеки не оказывается! А пользователь может быть любым, в том числе и созданным специально для таких экспериментов. Кстати, эта техника позволяет иметь несколько версий одной и той же программы, что не возможно (точнее, не всегда возможно) в Windows. Попробуйте, например, установить Office 97, Office 2000 и Office XP. Не получится, если только не прибегнуть к изощренным хакам, а в Linux/xBSD все это присутствует изначально.

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

Подведем итог. Linux/xBSD практически безболезненно переносят установку/удаление программ, в то время как при каждой инсталляции под Windows на нее нужно молиться, надеясь, что на этот раз «пронесет» и ничего не рухнет.

Модули и драйверы

Драйверы — неотъемлемая часть всякой операционной системы. Они могут быть включены как непосредственно в само ядро, без возможности загрузки дополнительных драйверов извне (и такое ядро называется монолитным), так и загружаться динамически по мере необходимости (и такое ядро называется модульным). Linux/xBSD могут быть собраны как с монолитным, так и с модульным ядром, в то время как все версии Windows построены по модульному принципу.

С одной стороны, это удобно, - особенно потрясает возможность подключения драйверов на лету без перезагрузки системы. Но в некоторых случаях создает огромные проблемы, поскольку от бесконтрольной загрузки/выгрузки драйверов страдает и стабильность, и безопасность. В 64-разрядной Windows Vista и Server 2003 была введена обязательная цифровая подпись для всех драйверов. Неподписанный драйвер можно загрузить только в отладочном реже, в который можно войти, выбрав соответствующую опцию из стартового меню системы. Другими словами, «левый» драйвер теперь уже не загрузить. Но выдача цифровой подписи и «сертификация» драйверов — чисто формальная процедура, и наивно полагать, что после нее драйверы станут лучше.

В Linux/xBSD исключение, возникающее внутри модуля (в смысле «драйвера», в терминологии Windows) приводит к остановке только этого модуля, позволяя системе работать и дальше. Конечно, если «полетит» дисковый драйвер или драйвер файловой системы, то это будет очень плохо, но дисковые драйверы неплохо отлажены, а вот без остальных компонентов жить вполне можно.

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

Статистика показывает, что большинство разрушений данных и дисковых томов происходит как раз из-за голубых экранов смерти. А разрушение намного коварнее простой потери несохраненных данных. И гарантированно застраховаться от него на Windows нельзя, особенно если компьютер подключен к Сети и принимает пакеты. Драйверы беспроводных устройств - сырые до невозможности, и ни одному поставщику не удалось избежать ошибок, а годами вылизываемый стек TCP/IP в Vista был переписан с чистого листа.

Linux/xBSD намного менее чувствительны к сбоям модулей, тем более что в большинстве случаев никаких новых модулей (в дополнение к уже имеющимся) устанавливать не придется. А все потому, что большинство Windows-драйверов на самом деле никакие не драйверы. Это программы, не управляющие никакими устройствами, но нуждающиеся в доступе к тем структурам ядра, до которых невозможно дотянуться через win32 API. В Linix/xBSD таких проблем не возникает, поскольку весь необходимый функционал уже вынесен на поверхность. Как говориться, пользуйся — не хочу.

Диски — логические и физические

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

Почему вообще умирают операционные системы? Вот так внезапно без всяких видимых причин… Причем, как показывает практика, Windows подвержена стихийным падениям в большей степени, чем Linux/xBSD.

Начнем с того, что, в отличие от Windows, Linux/xBSD способна грузиться (и нормально работать) с раздела, смонтированного в read-only, а все настройки и пользовательские данные держать в read-write разделе. Причем при желании часть критических настроек, которые не меняются каждый день, можно перенести в read-only раздел (что делается при помощи символических ссылок — hard link). Нетрудно догадаться, что такой системе практически ничего не угрожает. Ну, разве что хитрые вирусы какие-нибудь, работающие с правами root и имеющие прямой доступ ко всему, что шевелится. Но какие под Linux/xBSD вирусы?..

Если система не может писать на системный диск, она может работать годами, в худшем случае проявляя свой строптивый нрав эпизодическими перезагрузками. Чисто теоретически, кривой дисковый драйвер или паленое железо (например, жесткий диск с отколотым кусочком магнитной головки) способы разрушить данные даже при чтении, но это случается достаточно редко и уж во всяком случае намного реже, чем беспричинные падения Windows. Причин этих падений много. Коварная Windows постоянно что-то пишет в реестр, даже когда ее об этом не просят (достаточно запустить монитор реестра Марка Руссиновича, чтобы убедиться в этом). Позиции окон, текущая директория диалогового окна Open/Save as... Конечно, все эти пользовательские настройки не способны вызвать крах системы, но поскольку реестр один (практически один, строго говоря, он состоит из нескольких файлов), то на физическом уровне пользовательские настройки очень часто оказываются рядом с системными, разделяя с ними единый кластер, и при внезапных зависаниях, перезагрузках или отказах питания «хвост» кластера оказывается недописанным, в результате чего неудачная попытка записи пользовательских настроек гробит системные, а то и весь реестр целиком. Ведь реестр на структурном уровне представляет собой двоичное дерево, и повреждение одной из его ветвей «обрубает» все нижестоящие.

Допустим, есть UPS, страхующая нас от сбоев по питанию, и мы используем качественное железо и вылизанное программное обеспечение, практически никогда не вызывающее голубых экранов смерти и зависаний (критические ошибки — не в счет, реестру они не опасны, если, конечно, речь не идет об утилитах по управлению реестром). Может ли Windows неожиданно упасть в таком идеализированном случае? Не только может, но и должна! При завершении работы система дает всем приложениям (службам, драйверам и так далее) некоторое время для сохранения своих данных в реестре, и если кто-то из них не успевает это сделать, система безжалостно прерывает операцию записи прямо посередине. Результат — при последующем включении питания Windows имеет хорошие шансы не загрузиться или загрузиться не так, как мы этого ожидаем. Причем легальными средствами справиться с этой проблемой нельзя.

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

Некоторые интересуются, как Windows определяет, какие диски «чекать» при неправильном завершении работы системы, а какие не стоит. Все очень просто! При первом обращении к диску на запись в boot-секторе обновляется специальный флаг, указывающий, что диск не «clean». При сбросе всех дисковых буферов (который происходит время от времени), этот флаг снимается и вновь устанавливается, когда в буфер попадают данные, еще не записанные на диск. Задумаемся, что произойдет, если в момент обновления этого флага случится сбой питания, перезагрузка или зависание? Загрузочный сектор окажется разрушен и дисковый том станет недоступен, похоронив все данные. Хотя специалист их без труда сможет восстановить, этого специалиста еще где-то найти надо (и не только найти, но и заплатить), а для простого смертного пользователя потеря дискового тома — эта трагедия, граничащая с суицидом.

Наконец, самая неприятная новость. Все жесткие диски без исключения имеют свои внутренние кэши, и завершение операции обмена с винчестером еще не означает, что данные физически записаны на пластину. Старые диски с 4 Мб кэшем (и менее) успевали записать данные даже при выключении питания (за счет емкости электролитических конденсаторов и времени «выбега» пакета пластин). А вот у 8 Мб времени выбега уже не хватает, и потому даже при корректном завершении работы в Windows часть данных будет неизбежно потеряна. Для предотвращения этой напасти Microsoft выпустила специальный патч (а у вас он установлен?). В Linux/xBSD принудительный сброс дисковых буферов присутствовал от рождения, а все потому, что эти системы изначально ориентировались на серверное оборудование, на котором емкие кэши - не редкость, а вполне закономерное явление.

Шоссе в никуда

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

Крис Касперски Специалист по компьютерной безопасности и сжатию цифрового аудио/видео, системный программист, участвующий во многих проектах (большей частью под NDA) по анализу вредоносного программного обеспечения, поиску “закладок”, разработке систем защиты информации от несанкционированного досту- па/копирования информации как в качестве рядового сотрудника, так и руководителя отдела. В настоящее время работает в компании Endeavor Security, Inc, а так же занимается преподавательской деятельностью.

Обсуждение статьи

Логин: Пароль: Регистрации на сервере не требуется. Если у вас есть форумный логин, вы можете использовать его. Если нету, то вы можете зарегистрироваться на forum.itspecial.ru Для отправки сообщения введите код, указанный на картинке Заголовок Сообщение

Теги: BSD, Linux, Windows, восстановление, сбой, тема номера

Keywords: zPOSTz zMAIN_THEMEz z10015z
Для Авторов: edit delete