Windows: что будет, если повторно наложить горячий патч на функцию
Автор блога, который последние несколько дней изучал механизмы горячего патчирования (hot-patching, подмена кода функций без остановки системы), отвечает на вопрос: что будет, если кто-то пытается пропатчить функцию, которая уже пропатчена. Его ответ: если так случилось, значит, что-то пошло не так.
Горячее патчирование рассчитано на Windows Update в системах, где оно поддерживается (на момент написания, насколько понимает автор, это Windows Server, а позднее и Windows 11 Enterprise). Схема такая: приходит обновление, администратор заранее согласился на горячие патчи, а файл в обновлении помечен как «безопасный для горячего патчирования». Тогда Windows Update использует зарезервированное для этого место и заменяет затронутые функции на лету. Поскольку использовать это место разрешено только Windows Update, системе не нужно обрабатывать случай, когда функцию уже пропатчил кто-то другой: другого уполномоченного кода просто нет.
А если функцию перехватил (detour) или иначе изменил посторонний код, не имевший на это права? По прочтению автором кода горячего патчирования, при обнаружении такого «левого» патча код объявляет файл непригодным для горячего патчирования, и системе придётся перезагрузиться. Автор замечает, что это обычно не радует клиентов.
Отдельная проблема, состояние гонки. Предварительная проверка (prescan) может показать, что все функции безопасно патчить, но уже после неё кто-то успеет изменить функцию. Тогда патчер дойдёт до середины, обнаружит чужую правку и окажется в тупике: двигаться вперёд он не может, а надёжно откатиться тоже, потому что откат, вероятно, тоже сорвётся из-за наложенного поверх патча. В памяти остаётся наполовину пропатченный двоичный файл, и что будет дальше, неизвестно.
Итоговая аналогия: приложение, занявшее место для горячего патчирования, паркуется в пожарной зоне. Пока всё нормально, но когда приезжает пожарная машина, чей-то дом сгорает, потому что машина не может подъехать.
В сноске автор уточняет, что не всякое изменение годится для горячего патча. Например, если меняется раскладка или инварианты структуры данных, патч невозможен: уже созданные экземпляры структуры после патча окажутся в недопустимом состоянии.
Ключевые факты
- Горячее патчирование рассчитано только на Windows Update; другой код не уполномочен использовать зарезервированное под него место, поэтому система не предусматривает уже пропатченную кем-то функцию.
- Функция в Windows Server и, как понимает автор, в Windows 11 Enterprise патчится на лету, если администратор согласился на горячие патчи, а файл в обновлении помечен как безопасный для них.
- По прочтению автором кода, при обнаружении постороннего патча файл объявляется непригодным для горячего патчирования, и системе придётся перезагрузиться.
- Из-за состояния гонки между предварительной проверкой и самим патчированием возможен тупик: ни вперёд, ни надёжно назад, в памяти остаётся наполовину пропатченный файл.
- Не всякое изменение годится для горячего патча: правка раскладки или инвариантов структуры данных делает его невозможным.
Почему это важно
Заметка показывает граничный случай в устройстве Windows: механизм горячего патчирования исходит из того, что он единственный, кто меняет код функции. Нарушение этого допущения приводит либо к перезагрузке, либо, при гонке, к неопределённому состоянию. Это не новость об ИИ, а разбор внутреннего устройства системы.
Кому это важно
Разработчикам низкоуровневого ПО под Windows, в том числе тем, кто перехватывает функции (detour) в чужих модулях, а также администраторам Windows Server и Windows 11 Enterprise, где горячие патчи поддерживаются.
Как это применить
Практический вывод из текста один: не использовать место, зарезервированное под горячее патчирование, и не перехватывать функции в системных файлах, которые могут получить горячий патч. Автор сравнивает такое поведение с парковкой в пожарной зоне.
Можно ли доверять
Это авторское эссе, а не официальная документация. Поведение с перезагрузкой автор описывает как своё прочтение кода («my reading… suggests»), а не как подтверждённое утверждение. Автор в тексте не назван, реальных случаев столкновений, номеров сборок и измерений не приводится. Список поддерживающих систем дан «насколько можно судить» автору.
Риски и подводные камни
Если посторонний патч появится уже после предварительной проверки, патчер может застрять на полпути: продолжить нельзя, откат, вероятно, тоже не сработает, и в памяти окажется наполовину пропатченный двоичный файл. В остальных случаях, по прочтению автора, цена вмешательства, вынужденная перезагрузка, которая, по его словам, обычно огорчает клиентов.
«Всё как будто в порядке, пока не приезжает пожарная машина, и тогда чей-то дом сгорает дотла, потому что машина не может подъехать.»
— автор статьи