Сколько стоит упасть и отжаться

Автор: (c)Крис Касперски ака мыщъх

Важнейшая характеристика всякой операционной системы - ее надежность (в контексте устойчивости к сбоям) и среднее время "регенерации" после падений. Давайте сравним, насколько устойчива Windows и насколько - конкурирующая с ней Linux и почетный клон xBSD.

Введение или постановка задачи

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

Linux/xBSD

Рисунок 1. Черный консольный экран Linux/xBSD представляет собой настоящую крепость, хоть мрачную и неуютную, но зато неприступную.

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

Короче, мы попытаемся ответить на простой вопрос - можно ли обезопасить работу на Windows хотя бы в принципе и во что это обойдется в финансовом плане.

Windows

Рисунок 2. Windows же скорее напоминает живописное болото, но один шаг влево - и мы отказываемся по уши в липкой трясине.

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

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

"Не устанавливать непроверенные программы" - не предлагать. Эта гнилая отмазка не катит. Операционная система создана для того, чтобы работать, а не молиться на нее как на икону. Конечно, ставить все подряд может только энтузиаст, ламер или... журналист, описывающий новинки в мире софтвера. Да и простым специалистам знакомство с широким спектром программ никогда не помешает. Ограничивать себя минимальным набором прикладных и/или системных пакетов - это все равно, что в расцвете половой активности идти в монастырь (не женский). Короче, как ни крутись, а без установки программ не обойтись.

Установка новых программ на Windows

Рисунок 3. Установка новых программ на Windows всегда таит в себе потенциальный риск.

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

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

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

Вообще-то, Windows содержит встроенную утилиту MS Backup, позволяющую резервировать реестр и "жизненно важные" системные компоненты, что выручало мыщъх'а не раз и не два, однако возможности MS Backup более чем ограничены и спасают далеко не всегда. Короче, установка программ под Windows - это рулетка (русская), только в барабане заряжены все шесть патронов. Установив внешне безобидную программку, можно потратить целый день (а то и два), выковыривая ее из системы.

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

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

"configure" - это утилита такая, написанная в подавляющем большинстве случаев на языке оболочки sh (реже - bash) и формирующая make-файл на основе заданных ключей (указывающих, какие компоненты включать в программу, а какие - на фиг не надо), а также прочих личных предпочтений.

make-файл поступает на вход утилиты make, входящей в поставку любого Си-компилятора и осуществляющей всю процедуру сборки пакета (т.е. делающей полный build). "make install" вызывает из make-файла подпрограмму "install" (если ее можно назвать подпрограммой), содержащую вызовы команд оболочки операционной системы и копирующую все файлы/библиотеки/man'ы куда надо.

Фактически "make install" - это тот же самый инсталлятор, что и в Windows, и ему ничего не стоит разрушить систему, особенно при наличии прав root'а, но(!) при внешней схожести между ними есть огромное концептуальное различие: Windows-инсталляторы представляют собой двоичные файлы и мы не можем заглянуть к ним внутрь (если, конечно, не воспользуемся декомпилятором, но на это способен далеко не всякий пользователь).

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

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

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

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

Что поделаешь... мир несовершенен и рая на земле нет. Быть может, где-то там за ее пределами... Ладно, хватит лирики. Просто подведем итог. А итог таков, что Linux/xBSD практически безболезненно переносит установку/удаление программ, в то время как при каждой инсталляции под Windows на нее нужно молиться, надеясь, что на этот раз пронесет и ничего не рухнет.

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

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

С одной стороны - это удобно (особенно потрясает возможность подключения драйверов на лету без перезагрузки системы), но в некоторых случаях создает огромные проблемы, поскольку от бесконтрольной загрузки/выгрузки драйверов страдает и стабильность, и безопасность. В 64-разрядной Висте и Server 2003 была введена обязательная цифровая подпись для всех драйверов. Неподписанный драйвер можно загрузить только в отладочном режиме, в который можно войти только если явно выбрать соответствующую опцию из стартового меню системы. Другими словами, "левый" драйвер теперь уже не загрузить. Красота!!!

Но выдача цифровой подписи и "сертификация" драйверов - чисто формальная процедура и наивно полагать, что после нее драйвера станут лучше и безглючнее. Если даже монстры рынка, такие как NVIDIA, MATROX и TOSHIBA не способны выловить всех блок и предоставить качественный продукт, что уж говорить о мелких фирмочках и индивидуальных программистах!!!

Ошибки в драйверах были, есть и будут! А всякое необработанное исключение в драйверах уровня ядра (равно как и любая нештатная ситуация типа попытки освобождения уже освобожденной памяти), обрушивает Windows в Голубой Экран Смерти (он же Blue Screen Of Death или, сокращенно, BSOD), сопровождающийся потерей несохраненных данных и подчас стоящий жизни целого дискового тома!

Голубой Экран Смерти

Рисунок 4. Голубой Экран Смерти, возникающий на встраиваемых устройствах (например, таксофонах) способен нанести огромный финансовый убыток их владельцам.

В Linux/xBSD исключение, возникающее внутри модуля (ну, в смысле - "драйвера", в терминологии Windows) приводит к остановке только этого модуля, позволяя системе работать и дальше. Конечно, если "полетит" дисковый драйвер или драйвер файловой системы, то это будет очень-очень плохо, но дисковые драйвера неплохо отлажены, а вот без остальных компонентов жить вполне можно. Даже без видеокарты! Опытный пользователь (и уж тем более - администратор) запросто зашутданит систему и вслепую, сохраняя все несохраненные данные. И хотя время от времени ядро Linux'а впадает в панику (kernel panic), что равносильно BSOD, это случается намного реже и особой головной боли никому не доставляет.

FreeBSD

Рисунок 5. Даже при отказе Менеджера Виртуальной Памяти ("святая святых" операционной системы, FreeBSD продолжает хоть как-то работать, несмотря на то, что выполнение большинства команд становится невозможным).

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

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

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

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

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

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

FreeBSD

Рисунок 6. Под напором религиозной общественности FreeBSD меняет ориентацию.

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

Если система не может писать на системный диск, она может (и должна!) работать годами, в худшем случае проявляя свой строптивый нрав эпизодическими перезагрузками. Чисто теоретически - кривой дисковый драйвер или паленое железо (например, жесткий диск с отколотым кусочком магнитной головки) способны разрушить данные даже при чтении, но... это случается достаточно редко и уж во всяком случае намного реже, чем беспричинно падает Windows.

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

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

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

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

Гигантская плотность записи современных жестких дисков делает их крайне чувствительными к вибрации и ударам

Рисунок 7. Гигантская плотность записи современных жестких дисков делает их крайне чувствительными к вибрации и ударам.

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

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

Заключение или шоссе в никуда

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

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

Так что, делайте ставки, господа! Лично я работаю на Windows, но мой домашний файловый сервер (и рабочая станция по обработке цифрового видео по совместительству) вращается под Free BSD 4.5

Windows

Рисунок 8. Windows - это дымящийся вулкан, готовый проснуться в любую секунду.

Основные характеристики Windows и Linux/xBSD, относящиеся к отказоустойчивости

ОСУстановка программУстановка ПО в HOMEПесочницаЯдроРеакция на исключение внутри драйвераРабота в read-onlyХранитель конфигурации
WindowsДвоичные инсталляторыОтсутствуетНачиная с Vista, примитивнаяМодульноеАварийная остановка системыНевозможнаРеестр
Linux/xBSDТекстовые инсталляторыИмеетсяПрисутствует изначальноМонолитное или модульноеПродолжение работы системыВозможнаТекстовые файлы