Kontrola nad Windows NT

Błąd koncepcyjny w Windows NT umożliwiał zawieszenie systemu.

Błąd koncepcyjny w Windows NT umożliwiał zawieszenie systemu.

W grudniu ub.r. w Internecie zrobiło się głośno na temat rzekomego błędu w systemie operacyjnym Windows NT, umożliwiającego zawieszenie systemu przez aplikację, która przydzieli sobie najwyższy priorytet w systemie (w przypadku Windows NT - 15).

Przykładem takiej aplikacji jest CpuHog, dostępny pod internetowym adresemhttp://www.ntinternals.com/cpuhog.htm. Jego uruchomienie powoduje całkowite zawieszenie Windows NT (aplikacja uruchamia wykonywanie zapętlonego programu, który nie może zostać przerwany nawet przez Task Managera, ponieważ ma najwyższy priorytet w systemie). Jedynym rozwiązaniem problemu jest ponowne uruchomienie komputera.

Program działa w taki sposób wyłącznie na systemach jednoprocesorowych. W przypadku maszyn wieloprocesorowych obciąża on w pełni tylko jeden procesor, a co za tym idzie, pozostałe mogą obsłużyć inne zadania, umożliwiając przerwanie pracy CpuHoga. Oczywiście jest także możliwe napisanie aplikacji, która w pełni będzie wykorzystywać czas wszystkich procesorów, a więc problemem ten stanowi realne zagrożenie.

Poważny błąd?

Po zanalizowaniu problemu, zadałem sobie pytanie: czy działanie NT można uznać za błędne czy nie? Przydzielanie aplikacjom różnych priorytetów jest naturalne i należy się wręcz cieszyć, że system zachowuje się poprawnie (nie rezygnuje z realizacji wymagań aplikacji o najwyższym priorytecie). Tak więc z pewnością nie można uznać tego błędu za błąd techniczny.

Problem nazwałbym raczej błędem koncepcyjnym systemu, związanym z bezpieczeństwem Windows NT. Standardowe ustawienia systemu nie powinny umożliwiać uruchomienia aplikacji z najwyższym priorytetem i to zwykłemu użytkownikowi, nie mającemu uprawnień administratora. Zawsze w systemie powinien pracować "nadpriorytetowy" agent, umożliwiający w krytycznych wypadkach odzyskanie kontroli nad komputerem. Tutaj dostrzegam niedopatrzenie programistów Microsoftu.

Powstaje pytanie, ile istnieje aplikacji, które starają się w pełni przejąć kontrolę nad systemem i powodować jego zawieszenie? Przypuszczam, że bardzo niewiele i że nazywane są one wirusami. Każdy producent oprogramowania stara się, by pracowało ono poprawnie i kooperowało z systemem, a nie próbowało go zawiesić (a co za tym idzie samo zawieszało swoje działanie).

Problem istnieje...

Niemniej problem zaistniał i Microsoft musiał zająć stanowisko w tej sprawie. Sprawę potraktowano poważnie, uznając ją za błąd systemowy. Na serwerze Microsoftu w katalogu fttp://ftp.microsoft.com/bussys/winnt/winntüpublic/fixes/usa/NT40/hotfixes-postSP2/krnl-fix dostępna jest poprawka błędu dla Windows NT 4.0 w wersjach dla komputerów Intel, PowerPC i Alpha. Można ją instalować na komputerach, na których wcześniej zainstalowano zestaw poprawek systemowych Service Pack 2. Poprawka ta wejdzie także w skład Service Pack 3, który w ciągu trzech miesięcy powinien pojawić się na serwerze Microsoftu.

Poprawka zmienia działanie serwisu Scheduler Windows NT, dzięki czemu niepoprawnie działająca, zapętlona aplikacja z najwyższym priorytetem nie będzie już powodowała całkowitego wstrzymania pracy innych aplikacji i Task Managera. Możliwe będzie więc przerwanie jej pracy, poprzez skasowanie procesu, bez konieczności restartowania systemu.


TOP 200