Awaria to nie wina Microsoftu, ale Windows mógłby być lepszy [OPINIA]

Gdy tysiące komputerów z Windowsem przestały się poprawnie uruchamiać z powodu wadliwej aktualizacji CrowdStrike, w wielu serwisach informacyjnych odpowiedzialność przypisywano Windowsowi, a nie CrowdStrike. Nie oznacza to jednak, że Windows jest tu bez winy.

Opinia na temat stabilności i bezpieczeństwa Windows weszła już dawno do popkultury, co sprawia, że jest zamrożona w roku 2004 i pozostanie w nim na zawsze. System ten potocznie uchodzi za mało bezpieczny i skłonny do częstych awarii. Mimo oczywistych problemów, to niesprawiedliwa opinia. Windows jest dziś bardzo bezpiecznym systemem, a biorąc pod uwagę mnogość dostępnych konfiguracji, jego powszechne działanie jest niemal cudem.

CrowdStrike, który uległ awarii rozlanej na cały świat, instalował w Windowsie niskopoziomowy skaner/analizator, zaimplementowany w postaci sterownika działającego w trybie jądra. Awaria kodu działającego z tak wysokimi uprawnieniami kończy się awarią całego systemu. A wymagania te są niezbędne do tego, by narzędzie mogło spełniać swoje zadanie.

Crowdstrike Falcon Sensor nie byłby w stanie przeprowadzać bez nich analizy i wykrywać zagrożeń. Niestety, sterownik okazał się wadliwy, co skazało całe mnóstwo Windowsów na awarię uruchomienia i pętlę prób auto-naprawy, zakończonej niepowodzeniem. W świat poszły bzdurne informacje na temat powodów.

A wraz z nimi - niezbyt sensowne diagnozy. Komentowano, jak zwykle, że nie byłoby problemu, gdyby cały świat korzystał z Linuksa. Świadomość tego, że powszechnie używane systemy zawsze będą miały zainstalowane niskopoziomowe sterowniki bezpieczeństwa jest najwyraźniej rzadka. Powszechne użycie Linuksów skończyłoby się powszechnym użyciem np. modułu Trellix, co stworzyłoby potencjał na awarię w dokładnie tym samym stylu i o tej samej skali.

Ochrona przed malware'em zawsze będzie potrzebna i zawsze będzie istniało ryzyko błędnej aktualizacji, która położy system - niezależnie, jaki by on nie był. Z tym, że nie wolno zapominać o tym, że choć zawinił zewnętrzny komponent, to odporność Windowsa na takie problemy okazała się bardzo niska. Co dla niektórych malkontentów i wyznawców Pingwina jest "oczywiste", a wcale nie powinno.

Windows ma aż dwa relatywnie nowe mechanizmy zaprojektowane specjalnie do tego, żeby radzić sobie właśnie z takimi problemami. Oba wydają się być od lat kompletne mniej więcej w 70 proc. i najwyraźniej ich poprawienie nigdy nie jest priorytetem w Redmond.

Pierwszy mechanizm to automatyczna naprawa. W razie wykrycia kilku konsekutywnych nieukończonych rozruchów, Windows spróbuje samodzielnie naprawić problemy z uruchamianiem, błędami w BCD, odrzuconymi sterownikami i kilkoma innymi potencjalnymi źródłami kłopotów. Co jednak nie przestaje zdumiewać to fakt, automatyczna naprawa nie jest rozwijana, jest kiepsko udokumentowana i nie współpracuje z innymi mechanizmami. Windows od lat potrafi odrzucać błędne sterowniki, a od trzech dekad oferuje tryb awaryjny, startujący z minimalnym zestawem sterowników.

Automatyczne zablokowanie ładowania źródła awarii pozwoliłoby wystartować systemowi bez wadliwego sterownika. Próbne przejście w tryb awaryjny także pomogłoby przeskoczyć tę przeszkodę. Ale automatyczna naprawa tego nie robi, a tryb awaryjny wymaga ręcznego odblokowania BitLockera. Było to szczególnie zabawne w kontekście tego, że w firmach kopie klucza do ręcznego odblokowania znajdują się na kontrolerze domeny, który również mógł mieć wtedy awarię.

Można tu przyjść z ripostą, że sterownik może być oznaczony jako obowiązkowy (system może twierdzić, że rozruch bez niego jest niemożliwy), więc nie wyładuje go żaden tryb awaryjny i niezależnie od wykrytych problemów, system będzie obowiązkowo próbował ładować sterownik zainstalowany w taki sposób.

To prawda. Ale tu z pomocą przychodzi drugi mechanizm - ELAM. Jest to kategoria sterownika w Windows 8 i nowszych, informująca system, że sterownik ten nie jest sprzętowy i jego załadowanie ma nastąpić na najwcześniejszym możliwym etapie, przy minimalnym udziale zewnętrznych komponentów.

I ponownie jesteśmy w sytuacji, gdzie coś jest "prawie gotowe": sterowniki ELAM są traktowane osobno i możliwy jest rozruch wyłącznie bez nich. Nie trzeba wchodzić w ortodoksyjny i problematyczny tryb awaryjny, można zażądać rozruchu bez ELAM. To wspaniała opcja. Świadczy o tym, że w Microsofcie doskonale znany jest potencjał problemów dokładnie takich jak niedawna globalna awaria CrowdStrike i istnieje mechanizm wyłączania składników antywirusowych oddzielnie. Korzystałem z niego nieraz, gdy jakiś zewnętrzny antywirus uległ uszkodzeniu.

Ale… wybranie rozruchu bez ELAM też może nas zaatakować pytaniem o BitLocker, sterowniki ELAM mimo oddzielnego traktowania nie są wyładowywane automatycznie w razie awarii rozruchu, a wyłączenie ELAM nie zastąpi zewnętrznego narzędzia Defenderem, tylko wyłączy ochronę całkowicie. Wewnątrz Windowsa znajdują się wszystkie składniki uodparniające system na właśnie ten pechowy scenariusz z wadliwym antywirusem.

Powstały one nie bez powodu - widać, że kierowano się ochroną przed niskiej jakości oprogramowaniem zewnętrznym. W ich powstanie włożono wiele wysiłku, ale - co szokujące - składniki te nie są połączone w sensowną całość i naprawdę niewiele brakuje do tego, by Windows stał się niepodatny na takie globalne katastrofy jak draka z CrowdStrike.

W dalszym ciągu nie wykonano jednak koniecznego do tego rezultatu pracy, w konsekwencji czego wizerunkowo obrywa Windows - w powszechnej opinii zawinił Microsoft, a nie producent oprogramowania ochronnego. Poprawa tego stanu rzeczy wygląda na pilną, ale w Redmond bardzo rzadko ktokolwiek chce dotykać systemowe komponenty rozruchowe. Ostatnie lata dowiodły, że nierzadko kończy się to zablokowaniem Secure Boot, uszkodzeniem BIOS-u i awarią partycji odzyskiwania…