Во-первых, возможно ли взломать Windows и полностью удалить сообщение об ошибке BSOD и заменить его кодом "Смирись и разберись с ним", который заставляет ЦП перейти к следующей инструкции, как если бы ошибки не возникало? И если так, что случилось бы? Что будет делать это с компьютером? Я спрашиваю об этом, потому что, когда я начинаю писать свою собственную ОС для своего домашнего компьютера 68K, я хочу позволить пользователю выбирать между двумя вариантами, если возникает паника ядра: перезапустить или разобраться с этим и продолжать работать в обычном режиме. Я просто хочу быть уверенным в том, что произойдет, прежде чем я случайно разбью совершенно хорошее оборудование. И я мог бы попытаться взломать позже, когда я получу лучший компьютер.
1 ответ
BSOD - это просто визуальное сообщение об ошибке, которую Windows называет проверкой ошибок. Ошибки (или, как их называет * nix, паника ядра) происходят потому, что ОС не может "справиться с этим".
Например - инструкция пытается прочитать с адреса, который просто не существует. Или вызывает ошибку страницы, пытаясь прочитать память в обстоятельствах, когда ошибка страницы не может быть устранена.
Какие именно данные вы бы предоставили коду, которому нужен результат операции чтения, чтобы он мог "продолжаться"?
Эти ошибки обычно происходят, потому что рассматриваемая инструкция обращается к неправильному адресу. На какой адрес вы бы изменили его при повторной попытке? Откуда ты знаешь, что это должно было быть?
Конечно, эти ошибки могут возникать и при записи в память. Хорошо, вы можете просто не писать и продолжать. Но код не просто записывает в память, потому что это похоже на это. Некоторому другому коду позже понадобится та информация, которая должна была быть записана в память, и тогда у него будут те же проблемы с «просто продолжай». Подробнее об этом через минуту.
Возможным обходным путем будет большая изоляция компонентов. Предположим, что эта ошибка произошла в драйвере звуковой карты - довольно несущественное устройство для многих вещей, которые мы делаем на наших машинах. Вы можете сказать: «Давайте просто сообщим об ошибке и перестанем использовать звуковую карту до следующей перезагрузки, возможно, пользователь обновит драйвер или заменит звуковую карту».
Проблема в том, что весь код и данные в режиме ядра одинаково надежны. Ошибка, возникающая в режиме ядра, означает, что весь код и данные в режиме ядра, по только что увиденным свидетельствам, не заслуживают доверия. И нет никакого способа узнать, что он не нанес более тонкий ущерб до появления ошибки, замеченной ОС. (Это приводит к заклинанию «жертва не всегда является виновником». Очень часто обнаруживается, что код, вызвавший ошибку, сделал это, потому что какой-то другой компонент в режиме ядра испортил содержимое памяти. Часто бывает довольно сложно найти другой компонент.)
Еще один аспект подхода к проверке ошибок: об этих ошибках "сообщают" (сбой), как только они замечены (обычно потому, что они вызывают необработанное исключение). По нескольким причинам, связанных с ошибками, на самом деле можно было бы сделать что-то разумное и продолжать. Однако это скрывает тот факт, что произошла ошибка или произошла. Ошибки в режиме ядра, вероятно, в конечном итоге приведут к состоянию «я действительно не могу продолжить».
В приведенном выше примере неудачной записи в память вы можете сказать «так что просто не делайте запись». Но в конце концов что-то понадобятся данные, которые не были записаны, и тогда этот код упадет.
Сбой при первом признаке ошибки в режиме ядра, даже своего рода восстанавливаемого, приводит к тому, что вы получаете дамп памяти, максимально приближенный к проблеме. Многолетний опыт (с операционными системами, появившимися за десятилетия до того, как NT впервые была поставлена; как BSD, так и VMS датируются концом 70-х - началом 80-х), показал, что даже если вам удастся что-то исправить и продолжить, и система выйдет из строя позже будет гораздо сложнее найти проблему.
Проблема, скорее всего, не в том, что вы "сломаете хорошее оборудование". Дело в том, что просто нет возможности пожать плечами и продолжать идти, что, вероятно, приведет к счастливому результату. Это как добраться до развилки на дороге, но ваш GPS говорит вам идти прямо, пути, который не существует. Там нет никакого способа следовать в этом направлении, и нет никаких намеков относительно того, какую развилку взять. Вы можете выбрать путь случайным образом ... это вряд ли приведет к тому, что вы хотите идти. (Или стабильная ОС.)
Но если, скажем, каждый драйвер находился в какой-то отдельной песочнице или отдельном разделе памяти, то мы могли бы предположить, что он не повредил вне этого раздела, верно?
На самом деле да! Проблема в том, что вы не описываете архитектуру x86/x64 или то, как ОС обычно ее использует.
Но, хммм ... что если бы вы могли запускать каждый драйвер по-своему? Процессы изолированы друг от друга, верно? Если кто-то из них допустит такую ошибку, мы можем просто закрыть этот процесс, а остальная часть ОС продолжит работу.
Оказывается, для устройств, для которых скорость не так уж важна, можно! Это то, что представляет собой Windows "Рамки драйвера пользовательского режима".
Но для вызова этих драйверов пользовательского режима требуется очень длинный путь кода со многими переходами по кольцу и переключениями контекста между процессами. (Ну, долго по сравнению с вызовом драйвера режима ядра.) Вы не хотели бы использовать UMDF для ваших дисков или видеокарты. Вы можете переместить туда свои HID-драйверы, но HID-драйверы в значительной степени решают проблемы.
Тем не менее, есть некоторые устройства, которые могут выдерживать задержки (особенно на современных быстрых процессорах), и вы увидите, что в будущем все больше и больше драйверов переходят в режим пользователя. Для устройства, которое действительно нуждается в скоростях USB 3, драйвер UMDF, вероятно, будет слишком медленным, но устройство, которое может нормально работать на USB 1.1 (например, адаптер последовательного порта), вероятно, не будет возражать против использования функционального драйвера UMDF. С улучшениями в архитектуре UMDF, которые пришли с Win 8.1, вы увидите все больше и больше устройств, использующих UMDF.
По крайней мере, часть "драйвера шины", который обрабатывает интерфейс хост-контроллера USB для всех USB-устройств, все еще будет в режиме ядра, потому что он должен касаться портов и регистров ввода-вывода, и этот материал доступен только в режиме ядра; изменение, которое выбросило бы всю безопасность из окна.
Что приводит к этому: что касается основной операционной системы и драйверов режима ядра, им придется оставаться в режиме ядра, чтобы иметь возможность выполнять некоторые из своих функций - использование привилегированных инструкций, реагирование на прерывания и обрабатываемые исключения, доступ к оборудованию ввода-вывода ... все, что находится в частях "Системное программирование" ссылок на набор команд x86/x64. И я боюсь, что для необработанных исключений в коде режима ядра ответ "просто продолжай" остается "и что именно делать?""
Извините, если говорить прямо, но сказать, что неопределенная операция, предпринятая в режиме ядра, приведет только к сообщению об ошибке, и "разобраться с этим" означает неправильно понять, что должен означать режим ядра. Вы не можете просто придумать результат, и у вас есть основания думать, что последующий код будет вам доволен.