Жизнь после BSOD

Крис Касперски и Жирный Хомяк

Хакер, номер #085, стр. 085-114-8

[чего не умеет NTFS]

Для минимализации последствий краха системы, NT поддерживает специальные call-back'и. Всякий драйвер может вызывать функцию KeRegisterBugCheckCallback и зарегистрировать специальный обработчик, который будет получать управление в момент возникновения голубого экрана. Это позволяет корректно останавливать оборудование, например, парковать головки жесткого диска. Шутка! А вот драйверу файловой системы сбросить свои буфера ничуть не помешало бы, тем более что он может проверить их целостность по CRC или любым другим путем. Ходят устойчивые слухи, что NTFS именно так и поступает. Как бы не так! Мыщъх дизассемблировал NTFS.SYS и не нашел там никаких признаков вызова KeRegisterBugCheckCallback! В момент аварии буфера NTFS остаются не сброшенными, и она выживает только благодаря поддержке транзакций, при которых гарантируется атомарность всех операций, то есть операция либо выполняется, либо - нет. Обновление файловой записи не может произойти наполовину, и потому, в отличие от FAT, потерянные кластеры на ней не образуются. Ну, практически не образуются.

[не в шутку, не всерьез]

Рискну предположить, что на английский «ядрена вошь» переводится, как kernel bug. Нет, вы только представьте себе, что ещё наши прадеды, испытывая недостаток словарного запаса для излияния переполнявших их эмоций, пускались в нетривиальное обсуждение недостатков программных комплексов! Это ли не наглядное свидетельство генетической предрасположенности русского народа к высоким технологиям?!

(с) Leonid Loiterstein

[исключение и наказание]

Всегда ли помогает шунтирование KeBugCheckEx? Насколько это безопасно? Это очень опасно, тем более далеко не всегда помогает. Вот, например, рассмотрим следующий пример кода, позаимствованный из ядра:

[фрагмент кода, при котором шунтирование KeBugCheckEx заканчивается очень печально]

00565201 call ExAllocatePoolWithTag ; выделение памяти из лужи

00565206 cmp eax, ebx ; проверка успешности выделения памяти

00565208 mov ds:dword_56BA84, eax

0056520D jnz short loc_56521C ; -> нам дали память! живем, мужики!

0056520F push ebx ;

00565210 push ebx ;

00565211 push 6 ; с памятью вышел облом

00565213 push 5 ; отправляемся на небеса

00565215 push 67h ;

00565217 call KeBugCheckEx ;

0056521C loc_56521C: ; CODE XREF: sub_5651C1+4Cj

0056521C lea eax, [ebp+var_C] ; продолжаем нормальное выполнение

0056521F push ebx

00565220 push eax

Система выделяет память из общего пула, и если с памятью не облом, то происходит нормальное продолжение, в противном случае вспыхивает голубой экран. Допустим, мы закоротили KeBugCheckEx, что тогда? Нас обломали на память, а мы продолжаем нормальное выполнение, как ни в чем не бывало, обращаясь по указателю, который указывает в никуда. Возникает целый каскад вторичных исключений, а все структуры данных превращаются в труху, и система рушится окончательно. Вот так.