Я слышал от кого-то, что если незащищенная память выходит за пределы безопасной стены в режиме ядра, то оборудование может быть повреждено.
Это правда?
Если нет, что происходит, когда в режиме ядра возникает ошибка?
2 ответа
1
Синие экраны смерти случаются в ситуациях с ошибками ядра. Именно поэтому генерируется BSOD: для защиты от повреждения оборудования путем замораживания системы. «Ошибка, которую он не может разрешить» является двусмысленной. KMODE_EXCEPTION_NOT_HANDLED обычно генерируется в случае неизвестных ошибок. Ваш вопрос должен быть более точным, хотя.
0
Запись в ОЗУ, даже случайные данные, не повредит аппаратное обеспечение.
Если система прерывает запись файлов или данных на жесткий диск, данные на диске могут быть противоречивыми. Данные могут быть потеряны в результате. Но не будет никакого физического повреждения устройства.
Некоторые аппаратные устройства выглядят как ОЗУ для процессора. Современный пример - "Локальный APIC", который существует практически во всех современных процессорах x86. Однако запись случайных или непредвиденных данных здесь не приведет к повреждению оборудования, а скорее всего к блокировке вашей системы.
Программное обеспечение, управляющее системным вентилятором, работает в разделе памяти под названием "SMRAM". Обычно это совершенно недоступно для ОС. В некоторых системах возможно реактивировать его, но для этого необходимы записи в MSR и память. Если это не удастся, все современные процессоры отключатся, если они все равно перегреются.
Запись на флэш-память, то есть на ту же флэш-память, на которой установлена прошивка вашей системы (UEFI/BIOS), может помешать загрузке вашей системы. Технически оборудование не повреждено, но вы не сможете загрузить свою систему без физического перепрограммирования или замены прошивки.
Операционная система может обновить флэш-память. Однако это требует реализации протокола для отправки данных во флэш-память, а это означает, что это не так просто, как запись в ОЗУ. Я полагаю, что способ, которым это обычно реализуется, состоит в том, что утилиты обновления BIOS/UEFI фактически записывают обновленную прошивку в зарезервированную область ОЗУ или, возможно, во флэш-память, а затем она мигает самим BIOS при следующей загрузке. В этом случае ядро не работает во время обновления BIOS/UEFI, поэтому оно ничего не может сделать.
UEFI имеет системные переменные, которые могут быть прочитаны и записаны, и имеет ограниченное пространство для этих переменных, и предоставляет интерфейс, где эти переменные могут быть обновлены. Возникла проблема с некоторыми материнскими платами, когда запись большего количества данных, чем может занимать это пространство, приводила к повреждению прошивки и не загружало систему при перезапуске. Это не имело никакого отношения к сбою ядра, но было ошибкой в прошивке.
Что происходит во время сбоя режима ядра? Что-то - либо обработчик исключений, либо функция в ядре Windows, либо драйвер - вызывает функцию API Windows под названием KeBugCheckEx:
Независимо от причины сбоя системы, функция, которая фактически выполняет сбой, - это
KeBugCheckEx, задокументированная в Windows Driver Kit (WDK).Эта функция принимает код остановки (также называемый кодом проверки ошибок) и четыре параметра, которые должны интерпретироваться для каждого кода остановки.
После того, как
KeBugCheckExмаскирует все прерывания на всех процессорах системы, он переключает дисплей в графический режим VGA с низким разрешением (один реализован на всех поддерживаемых Windows видеокартах), закрашивает синий фон и отображает код остановки, а затем некоторые текст, предлагающий, что пользователь может сделать.Наконец,
KeBugCheckExвызывает любые зарегистрированные обратные вызовы для проверки ошибок драйвера устройства (регистрируемые путем вызова функцииKeRegisterBugCheckCallback), позволяя драйверам останавливать свои устройства.Затем он вызывает зарегистрированные обратные вызовы причины (зарегистрированные с помощью функции
KeRegisterBugCheckReasonCallback), которые позволяют драйверам добавлять данные в аварийный дамп или записывать информацию аварийного дампа на альтернативные устройства.
После этого есть пара шагов (обновлю, если найду ссылку). Подводя итог, в основном он отключает все прерывания, вызывает любые драйверы, которые хотели вызвать во время сбоя, вызывает любые драйверы, которые добавляют или вносят изменения в дамп сбоя, затем записывает информацию дамп сбоя и либо останавливает, либо перезапускает.