Acpi s3 что это

ACPI S3

Опция дает возможность указать, будет ли использоваться режим энергосбережения Suspend to RAM при переходе в спящий режим (Enabled), или нет (Disabled).

Кратко остановимся на режимах энергосбережения. Большинство компьютеров, поддерживающих спецификации ACPI, позволяют использовать два режима: S1 (POS) и S3 (STR). В первом (расшифровывается как Power on Suspend) отключается питание от жесткого диска, некоторых карт расширения, плюс, гасится монитор. Все остальные компоненты (процессор, оперативная память, чипсет…) работают в штатном режиме, возможен только переход на пониженные частоты. Благодаря этому пробуждение происходит очень быстро. Второй режим (сокращение от Suspend to RAM) характеризуется гораздо меньшим энергопотреблением. Перед переходом в него вся информация о состоянии различных компонентов сохраняется в оперативной памяти, после чего все остальные устройства отключаются, остается только дежурное питание. Расплачиваться за это приходится более долгим пробуждением компьютера. Есть еще Hibernate или Suspend to Disk, но он не относится к режимам энергосбережения. При его использовании информация о состоянии различных компонентов «сбрасывается» на жесткий диск, после чего происходит обычное отключение питания.

Для того чтобы режим Suspend to RAM (как, впрочем, и Suspend to Disk) функционировал без сбоев, необходимо четкое взаимодействие всех драйверов компонентов, установленных в системе. При наличии «кривого» драйвера компьютер может не просыпаться вообще или после выхода из спящего режима работать с ошибками. В этом случае необходимо вернуться к менее требовательному в этом плане Power on Suspend.

Режим Suspend to RAM накладывает определенные ограничения на блок питания: ток, отдаваемый по цепи Standby (+5V SB), должен быть не менее 800 мА (рекомендуется 1 А). К современным моделям претензий в этом плане нет — все они совместимы с режимом Suspend to RAM, проблемы могут возникнуть только со старыми компьютерами.

О безопасности UEFI, часть третья

Продолжаем разговор о безопасности UEFI.
На этот раз речь пойдет об опубликованной в конце 2014 года серьезной уязвимости в реализации ACPI S3 (Sleep Mode), ее эксплуатации и последствиях. Основная «фишка» этой уязвимости в том, что она вскрыла целый класс проблем безопасности UEFI, вообще не считавшихся до этого проблемами, и потому и заслуживает отдельной статьи.
Тем, кто не читал предыдущие статьи цикла — раз и два, предлагаю прочесть сначала их, остальных жду под катом.

Часть третья. ACPI S3

Еще немножечко ликбеза

S0 — Working, т.е. обычная работа, все устройства включены. Внутри этого состояния производители систем имеют право определять кучу других состояний: P -states, C -states, T -states и т.п., расскажу о них как-нибудь в другой раз.
S1 — Sleeping with Processor Context Maintained, оно же Power on Suspend, т.е. все ядра процессора выполнили команду HLT и стоят, но все кэши и RAM валидны и обновляются, питание со всех все линий S0-only снято. Возврат из этого состояния занимает приблизительно 10 мс, из которых ~90% — ожидание установившихся режимов после подачи питания на линии S0-only. Никакие регистры ни у CPU, ни у чипсета, ни у устройств в этом состоянии не сбрасываются, так что нас в этой статье оно интересовать не будет.
S2/S3 — Suspend to RAM, т.е. содержимое памяти остается валидным и обновляется, а процессор и часть чипсета отключаются полностью с потерей контекста и содержимого практически всех регистров. Разница между S2 и S3 минимальная, и чаще всего S2 вообще не выделяют в отдельное состояние. После пробуждения из S3 процессор начинает выполнять код с ResetVector’а, т.е. чтобы правильно «проснуться», ему нужно восстановить весь контекст для себя и чипсета. Вот на этом этапе разработчиков прошивки и подстерегает несколько подводных граблей, о которых мы и поговорим в этой статье.
S4 — Suspend to Disk, т.е. содержимое памяти сбрасывается на диск и система отключает все устройства и подачу питания. После включения система стартует как обычно, и с точки зрения UEFI между S4 и S5 разницы практически нет (а если отключить FastBoot, то совсем нет).
S5 — Soft-Off, т.е. система отключена, но дежурное питание присутствует. Из S4/S5 система может быть выведена по сигналу RTC , либо по Wake-сигналу от устройства, либо по нажатию кнопки питания.

Как реализован S3 в UEFI

Чтобы восстановить контекст при «просыпании», сначала его нужно где-то сохранить. При этом желательно не слишком привязываться к конкретным особенностям архитектуры процессора и чипсета, а таже сделать хранение и восстановление контекста максимально прозрачным, чтобы не умереть потом в отладке. Т.к. работоспособность S3 — очень важная характеристика практически любого современного ПК, за исключением серверов с годами аптайма, то технология сохранения и восстановления контекста была разработана инженерами Intel очень рано, в 2004 году, и получила название EFI S3 BootScript. С тех пор спецификация многократно дорабатывалась, последняя версия теперь находится в томе 6 спецификации UEFI PI .
Суть ее такова: после исполнения фазы PEI , в которой происходит инициализация базовых устройств, т.е. процессора, кэшей и оперативной памяти, система определяет текущий режим загрузки.
1. Если этот режим отличается от S3 Resume, загрузка продолжается как обычно, PEI заканчивается запуском диспетчера DXE , который создает новый пустой S3 BootScript и запускает все доступные DXE-драйверы. Каждый такой драйвер выполняет финальную инициализацию того устройства, за которое он отвечает, и затем добавляет в S3 BootScript команды, которые необходимо выполнить, чтобы повторить инициализацию устройства при возврате из S3. Команды могут быть примерно такими (список взят из спецификации PI 1.4, но в конкретных реализациях могут встречаются и нестандартные):

IO_WRITE — записать указанное значение в указанный CPU IO-порт
IO_READ_WRITE — изменить значение в указанном CPU IO-порту согласно указанной маске
IO_POLL — выполнять чтение из указанного IO-порта, пока не будет выполнено указанное условие, но не дольше указанного времени ожидания
MEM_WRITE — записать указанное значение по указанному физическому адресу
MEM_READ_WRITE — изменить значение по указанному физическому адресу согласно указанной маске
MEM_POLL — выполнять чтение по указанному адресу, пока не будет выполнено указанное условие, но не дольше указанного времени ожидания
PCI_CONFIG_WRITE — записать указанное значение по указанному адресу в конфигурационном пространстве указанного PCI-устройства
PCI_CONFIG_READ_WRITE — изменить значение по указанному адресу в конфигурационном пространстве указанного PCI-устройства согласно указанной маске
PCI_CONFIG_POLL — выполнять чтение по указанному адресу в конфигурационном пространстве указанного PCI-устройства, пока не будет выполнено указанное условие, но не дольше указанного времени ожидания
SMBUS_EXECUTE — передать указанную команду указанному устройству на шине SMBus
STALL — подождать указанное число микросекунд
DISPATCH — выполнить код по указанному адресу

Вышеуказанных команд вполне достаточно, чтобы повторно инициализировать любое устройство, особенно с учетом последней команды, просто передающей управление PEI-драйверу, который и выполняет всю инициализацию, но нужно это только для особо сложных случаев, когда остальными командами обойтись не получилось.
После окончания фазы DXE диспетчер сохраняет получившийся S3 BootScript в памяти типа AcpiNVS , в которой находятся ACPI-таблицы и другие данные, необходимые ОС для правильной работы ACPI в ней.
2. Если же при загрузке выяснилось, что система находится в S3 Resume, вместо диспетчера DXE запускается PEI-модуль с красивым именем BootScriptExecutor, который выполняет BootScript, бережно хранящийся в памяти со времен прошлой нормальной загрузки, а затем передает управление на ОС, которая успешно стартует и радует пользователя.
Словами, вроде бы, пояснил, теперь тоже самое — картинкой из спецификации:

Подводные грабли

Это все успешно работало около 10 лет, и практически никто не видел подвоха, пока в конце 2014 года широко известные в узких кругах товарищи Rafal Wojtczuk and Corey Kallenberg не представили атаку, которая оказалась одновременно очевидной и крайне опасной. Оказалось, что область памяти (типа AcpiNVS), которой хранится S3 BootScript, никак не защищена от модификации. Да, ОС воспринимает ее как служебную и не испортит содержимое самостоятельно, а вот атакующий с правами администратора — еще как.
Модификации могут быть весьма различными, но т.к. большая часть защитных механизмов, обеспечивающих защиту как от прошивки произвольно кода в микросхему SPI, так и от несанкционированного доступа в SMM, настраиваются через регистры процессора и чипсета, то для успешного обхода этих механизмов достаточно найти BootScript в памяти (это нетрудно), найти в нем нужный нам регистр (тоже никаких сложностей) и изменить его так, чтобы при следующем S3 Resume защита не смогла включиться. Меняем, засыпаем, просыпаемся — оп, а король-то голый! Чем грозит снятие защиты с микросхемы SPI и с SMM — я уже писал в прошлых частях, повторяться не буду, но ничем хорошим это определенно не закончится.
Интересно, что инженеры Intel предвидели эту атаку и заранее реализовали защиту от нее — т.н. SmmLockBox. Защита очень простая — после того, как составление скрипта закончится, он копируется целиком в SMRAM, при этом оригинальный BootScript не удаляется. При восстановлении из S3 вызывается обработчик SMI, который проверяет, что оригинальный BootScript совпадает с копией в SMRAM, а если нет — либо переписывает измененный BootScript копией, либо перезагружает машину (это безопаснее, но пользователь теряет все данные из RAM). Проблема оказалась в том, что SmmLockBox просто не успели вовремя внедрить, и когда Rafal и Corey тестировали найденную уязвимость, оказалось, что единственная неуязвимая к атаке плата — Intel’овский UEFI Development Kit.
После обнародования атаки IBV начали в спешке внедрять либо оригинальный SmmLockBox, либо свои аналоги, основанные на той же идее, но это внедрение часто буксовало по разным причинам. К примеру, на системах с процессором AMD инициализация SMM проводилась в фазе DXE, и потому вызов обработчика SMI из PEI при S3 Resume заканчивался неудачей и S3 переставал работать вообще.
Тем не менее, на данный момент все вендоры, слышавшие о безопасности хотя бы краем уха, уже решили эту проблему каким-либо способом, и если ваша прошивка новее июня 2015 года, а производитель вашей системы не мудак — скорее всего ваша система прямой атаке на изменение S3 BootScript’а уже не подвержена.

Свинья от производителей платформ

После того, как паника немного улеглась, и BootScript успешно затолкали в SMRAM (понятно, что теперь надо хранить его как зеницу ока, но я об этом уже в прошлой части писал), неожиданно выяснилось, что инженеры Intel и AMD, сами того не зная, подложили обладателям своих платформ порядочную свинью в лице нескольких PEI-модулей, которые а) копировались в память прямо рядом с BootScript’ом, б) вызывались из него командой DISPATCH десятки раз и в) были достаточно большими, чтобы в SMRAM на их копии места не хватало.
Таким образом, выполнение произвольного кода можно было организовать без модификации самого BootScript’а вообще, вместо этого модифицировав точку входа одного из таких модулей. Удалить такие модули без нарушения работы S3 не получалось, но решение нашлось — вместо копирования в память их перенесли на неупакованную часть DXE-тома, и исправили команды DISPATCH так, чтобы код вызывался прямо с микросхемы SPI. Это оказалось немного медленнее, чем из RAM, зато свинью удалось таки выгнать. Я не знаю, сколько сейчас систем, которые можно атаковать этим способом, но подозреваю, что очень много.

Господа забывчивые

Человек не застрахован от ошибок, и разработчики DXE-драйверов — тоже человеки, и иногда могут банально забыть написать добавление какого-нибудь важного регистра в BootScript, и после S3 в этом регистре окажется его оригинальное значение. Чаще всего такая забывчивость приводит только к мелким глюкам после S3, но законы Мерфи говорят нам, что если какой-либо важный регистр может быть забыт — он обязательно будет забыт, что и происходит. Последний громкий пример забывчивости — опубликованная в конце мая этого года уязвимость в прошивках ноутбуков Apple, где инженеры забыли добавить в S3 BootScript запись в PR-регистры, и после S3 защита микросхемы SPI от прошивки снималась самостоятельно. Очень удобно ведь, закрыл-открыл крышку — и можно доставать flashrom и писать свой код в BIOS, Apple вновь радует простой и юзабилити. Если вы думаете, что случай единичный — советую запустить на своем ПК утилиту Chipsec и сравнить отчеты, сделанные до и после S3. Заодно и сюрприз может получиться.

Отключу S3 и трава не расти

Примерно это, только более экспрессивно и немного более матом, я воскликнул, когда столкнулся с проблемой впервые. К сожалению, этот вариант не всегда возможен (хотя S4 на SSD мало отличается по скорости, зато сильно отличается по надежности, никаких танцев со скриптами и экзекуторами не нужно), более того, если вы не отключили S3 намертво путем модификации прошивки, атакующий, способный запустить на вашей системе UEFI Shell, банально включит S3 обратно. В следующей части я постараюсь рассказать, как избежать такой незавидной судьбы, но коротко — включайте и пользуйтесь SecureBoot, он вовсе не зло, если уметь его готовить.

Кризис доверия

Вся эта история с S3 BootScript вскрыла одну интересную проблему, которую после 10 беззаботных лет разработки в UEFI серьезно начали решать только сейчас. Проблема состоит в том, что «безопасная» прошивка не может доверять ничему, к чему имеет или имела доступ ОС. Устройства нужно сбросить и инициализировать самостоятельно, память очистить и ничего из нее не использовать (не дай рандом вызывать оттуда код!), свои же Runtime-сервисы после события ReadyToBoot компонентам прошивки использовать нельзя (их уже хукнул атакующий, иногда по нескольку раз), в общем, сплошное минное поле, чуть оступился — и вот у тебя уже полный BIOS чужого кода, бэкдор на бэкдоре, честным драйверам в SMRAM места нет. Поэтому производители платформ ищут спасения в аппаратных решениях, кто-то внедряет validated boot, кто-то хранит S3 BootScript в Security Coprocessor’е, кто-то разрабатывает свой собственный крипточип, кто-то просто забил и ждет, пока ему решение UEFI Forum сверху спустит.
Вот и Intel добавила в Skylake интересную технологию SGX , которую можно использовать для изоляции отдельных кусков кода и данных от всего остального в системе, такой себе аналог SMM, только всем и даром, чтобы никто не ушел обиженным. Технология выглядит достаточно вкусно, но, во-первых, сложна в программировании, а во-вторых — есть только у Intel и только на Skylake.
Со стороны «безопасной» ОС — такой же точно уровень недоверия к прошивке, и тут может пригодиться технология STM , о которой разговоры велись с 2009 года, но представили ее официально только недавно, и «в бою» она еще не опробована. Когда дойдут руки попробовать обе — постараюсь про это написать.

Заключение

Ну вот, проблемы с S3 BootScript позади, в следующей части поговорим об атаках на NVRAM и SecureBoot, а также о том, почему пароль на BIOS — от честных людей.
По доброй традиции, посоветую знатокам английского языка вот эту статью тов. d_olex на ту же тему. Там серьезность, глубина, код, и картинки, не то что мое словоблудие тут.
Спасибо тебе за внимание, читатель, безопасных тебе прошивок.

Информационная безопасность
Системное программирование
UEFI

Опция BIOS — ACPI Suspend Type

С помощью опции ACPI Suspend Type можно установить режим энергосбережения персонального компьютера, который будет использоваться при переходе ПК в состояние энергосбережения.

S1 (или POS, или S1 State) – режим S1;

S3 (или STR, или S3 State) – выбор режима S3;

S1&S3 (или Auto) – поддержка одновременно режимов S1 и S3.

Опция также может иметь другие названия:

ACPI Sleep Type

ACPI Standby State

ACPI Suspend Mode

ACPI Suspend State

ACPI Suspend Type

Sleep State

Suspend Mode

Примечание 1. Power On Suspend, POS, Doze) – режим энергосбережения, при котором отключается монитор, винчестер, но на центральный процессор и ОЗУ (модули оперативной памяти) питание подается, снижается частота системной шины. Процессорные кэши сброшены, процессоры не выполняют инструкции, отключен генератор тактовой частоты ЦП.

Примечание 2. S3 (Suspend to RAM, STR, Suspend) – ждущий режим. При данном режиме энергосбережения питание подается только на оперативную память (в ней хранится информация о состоянии системы). Все другие компоненты ПК отключены.

Более подробно о режимах энергосбережения Вы можете узнать здесь.

Программа Setup BIOS фирмы AWARD Software International Inc на системных платах GIGABYTE TECHNOLOGY

Название данной опции у данного производителя в данной версии BIOS:

ACPI Suspend Type значение по умолчанию [S1(POS)]

Обозначение опции BIOS	Описание опции в БИОСе	Переведенное значение опции БИОС
[S1(POS)] — первый режим уменьшенного энергопотребления	Set suspend type to Power On Suspend under ACPI OS	Установить тип подачи питания — энергосбережения (активно только ОЗУ и ЦП).
[S3(STR)]- третий режим уменьшенного энергопотребления	Set suspend type to Suspend to RAM under ACPI OS	Установить подачу питания только к оперативной памяти — ждущий режим.

Состояния питания системы

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

Системные интеграторы и разработчики, создающие драйверы или приложения с помощью системной службы, должны быть особенно осторожны при проблемах с качеством драйверов, таких как утечки памяти. Хотя качество драйверов всегда было важным, время ожидания между перезагрузками ядра может быть значительно дольше, чем в предыдущих версиях ОС, так как ядро, драйверы и службы сохраняются и восстанавливаются, а не повторно запускаются в спящем режиме и завершении работы пользователя.

В следующей таблице перечислены состояния питания ACPI от самого высокого до самого низкого энергопотребления.

Состояние электропитания	Состояние ACPI	Описание
Выполняется операция	S0	Система полностью пригодна для использования. Аппаратные компоненты, которые не используются, могут экономить электроэнергию, перейдя в более низкое состояние питания.
Спящий режим (современный режим ожидания)	Бездействующий режим S0 с низким энергопотреблением	Некоторые системы SoC поддерживают состояние простоя с низким энергопотреблением, известное как современный режим ожидания. В этом состоянии система может очень быстро переключиться из состояния с низким энергопотреблением в состояние высокой мощности в ответ на аппаратные и сетевые события. Системы, поддерживающие современный режим ожидания, не используют S1–S3.
Сон	S1 S2 S3	Система, как представляется, отключена. Объем потребляемой энергии в состояниях S1–S3 меньше S0 и больше , чем S4. S3 потребляет меньше энергии, чем S2, а S2 — меньше, чем S1. Системы обычно поддерживают одно из этих трех состояний, а не все три.

В состояниях S1–S3 энергонезависимая память обновляется для поддержания состояния системы. Некоторые компоненты по-прежнему питаются, поэтому компьютер может выйти из режима ввода с клавиатуры, локальной сети или USB-устройства.

Гибридный спящий режим, используемый на настольных компьютерах, — это место, где система использует файл гибернации с S1-S3. Файл гибернации сохраняет состояние системы на случай, если система потеряет питание во время спящего режима.

Перечисление SYSTEM_POWER_STATE определяет значения, используемые для указания состояний питания системы.

Рабочее состояние: S0

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

Выключите аппаратные компоненты, когда они не используются, независимо от состояния. Низкое энергопотребление является важным фактором для потребителей мобильных устройств.

Состояние спящего режима: современный режим ожидания

В режиме простоя S0 с низким энергопотреблением рабочего состояния, также называемом современным режимом ожидания, система остается частично запущенной. В режиме современного режима ожидания система может оставаться в актуальном состоянии всякий раз, когда доступна подходящая сеть, а также пробуждение при необходимости выполнения действий в режиме реального времени, таких как обслуживание ОС. Современный режим ожидания выходит из спящего режима значительно быстрее , чем S1–S3. Дополнительные сведения см. в разделе Современный режим ожидания.

Современный режим ожидания доступен только в некоторых системах SoC. Если она поддерживается, система не поддерживает S1-S3.

Не включайте пробуждение S3 по локальной сети (WoL) в современных системах с поддержкой Standaby. Пробуждение компьютера с помощью магического пакета изначально поддерживается современным резервным режимом. Включение устаревших S3 WoL не требуется и может привести к бурям пакетов DHCP и (или) DNS в сети.

Состояние спящего режима: S1–S3

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

Перед переходом системы в спящий режим она определяет соответствующее состояние спящего режима, уведомляет приложения и драйверы об ожидающих переходе, а затем переводит систему в спящий режим. В случае критического перехода, например при достижении порогового значения батареи, система не уведомляет приложения и драйверы. Приложения должны быть готовы к этому и предпринять соответствующие действия, когда система возвращается в рабочее состояние.

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

При вызове SetThreadExecutionState значение должно использоваться только в случае крайней необходимости приложениями мультимедиа, ES_AWAYMODE_REQUIRED которым требуется, чтобы система выполняла фоновые задачи, такие как запись телевизионного содержимого или потоковая передача мультимедиа на другие устройства, пока система работает в спящем режиме. Приложения, которые не требуют критической фоновой обработки или работают на переносных компьютерах, не должны включать режим «вне сети», так как это не позволяет системе экономить энергию, перейдя в режим реального спящего режима.

Гибридный спящий режим: S1–S3 + файл гибернации

Гибридный спящий режим — это специальное состояние, которое представляет собой сочетание состояний спящего режима и гибернации. Это когда система использует файл гибернации с S1-S3. Гибридный спящий режим доступен только в некоторых системах. Если этот параметр включен, система записывает файл гибернации, но переходит в спящий режим с более высоким уровнем мощности. Если питание теряется во время спящего режима, система выходит из спящего режима, что занимает больше времени, но восстанавливает состояние системы пользователя.

Состояние гибернации: S4

Windows использует гибернацию для быстрого запуска. Если он доступен, он также используется на мобильных устройствах для продления срока использования батареи системы, предоставляя механизм для сохранения всего состояния пользователя до завершения работы системы. При переходе в режим гибернации все содержимое памяти записывается в файл на основном системном диске — в файл гибернации. Это сохраняет состояние операционной системы, приложений и устройств. В случае, когда совокупный объем памяти занимает всю физическую память, файл гибернации должен быть достаточно большим, чтобы обеспечить место для сохранения всего содержимого физической памяти. Так как данные записываются в энергонезависимое хранилище, DRAM не требует поддержки самообновления и может быть выключена, что означает, что потребление энергии в режиме гибернации очень низкое, что почти так же, как и выключение питания.

Во время полного завершения работы и загрузки (S5) весь сеанс пользователя снимается и перезапускается при следующей загрузке. В отличие от этого, во время гибернации (S4) сеанс пользователя закрывается, а состояние пользователя сохраняется.

Быстрый запуск: сокращен файл гибернации

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

При использовании быстрого запуска система кажется пользователю, как будто произошло полное завершение работы (S5), несмотря на то, что система фактически прошла через S4. Сюда входит то, как система реагирует на оповещения о пробуждении устройства.

Быстрый запуск выполняет выход из сеансов пользователя, но содержимое ядра (сеанс 0) записывается на жесткий диск. Это обеспечивает более быструю загрузку.

Чтобы программно инициировать быстрое завершение работы в стиле запуска, вызовите функцию InitiateShutdown с флагом SHUTDOWN_HYBRID или функцию ExitWindowsEx с флагом EWX_HYBRID_SHUTDOWN .

В Windows быстрый запуск является переходом по умолчанию при запросе завершения работы системы. Полное завершение работы (S5) происходит при запросе перезагрузки системы или при вызове API завершения работы приложением.

Ввод режима гибернации

При выполнении запроса гибернации при переходе системы в режим гибернации выполняются следующие действия:

Уведомления о приложениях и службах
Водители получают уведомления
Состояние пользователя и системы сохраняется на диск в сжатом формате
Уведомление о встроенном ПО

Все ядра в системе используются для сжатия данных в памяти и их записи на диск.

Чтобы программно инициировать переход в режим гибернации, вызовите функцию SetSuspendState .

Возобновление режима гибернации

Когда система возобновляется из гибернации.

Когда система включена, по мере возобновления работы системы из режима гибернации выполняются следующие действия:

Системный POST
Системная память распаковка и восстановление из файла гибернации
Инициализация устройства
Драйверы восстанавливаются до состояния, в которое они находились до гибернации
Службы восстанавливаются до состояния, в которое они находились до гибернации
Система становится доступной для входа

Возобновление из гибернации начинается с системного post, аналогичного завершению работы S5. Диспетчер загрузки ОС определяет, что требуется возобновление гибернации, обнаруживая допустимый файл гибернации. Затем он направляет систему на возобновление работы, восстанавливая содержимое памяти и все архитектурные регистры. В случае возобновления режима гибернации содержимое системной памяти считывается обратно с диска, распаковывается и восстанавливается, что приводит к тому, что система находилась в точном состоянии, в котором она находилась на момент гибернации. После восстановления памяти устройства повторно запускаются, компьютер возвращается в запущенное состояние, готовое к входу.

Во время возобновления режима гибернации драйверы и службы получают уведомление, но не перезапускаются. Они восстанавливаются только в том состоянии, в которое они находились до гибернации.

Типы файлов гибернации

Файлы гибернации используются для гибридного спящего режима, быстрого запуска и стандартной гибернации. Существует два типа, различаемых по размеру, полный и уменьшенный файл гибернации. Только быстрый запуск может использовать сокращенный файл гибернации.

Тип файла гибернации	Размер по умолчанию	Поддерживает.
Полное	40 % физической памяти	гибернации, гибридный спящий режим, быстрый запуск
Снижение	20 % физической памяти	быстрый запуск

Чтобы проверить или изменить тип используемого файла гибернации, запустите служебную программуpowercfg.exe . В следующих примерах показано, как. Чтобы получить дополнительные сведения, запустите powercfg /? hibernate .

Пример	Описание
powercfg /a	Проверьте тип файла гибернации. Если используется полный файл гибернации, в результатах будет указано, что гибернация является доступным вариантом. Если используется сокращенный файл гибернации, результаты говорят, что гибернация не поддерживается. Если в системе вообще нет файла гибернации, в результатах будет указано, что гибернация не включена.
powercfg /h /type full	Измените тип файла гибернации на полный. Это не рекомендуется для систем с объемом хранилища менее 32 ГБ.
powercfg /h /type reduced	Измените тип файла гибернации на сокращенный. Если команда возвращает «неправильный параметр», см. следующий пример.
powercfg /h /size 0 powercfg /h /type reduced	Повторите попытку, изменив тип файла гибернации на сокращенный. Если для файла гибернации задан пользовательский размер, превышающий 40 %, необходимо сначала задать нулевой размер файла. Затем повторите попытку уменьшенной конфигурации.

Состояние мягкого выключения: S5

Состояние обратимого выключения — это полное завершение работы системы без файла гибернации. Обратимое отключение также называется полным завершением работы. Во время полного завершения работы и загрузки весь сеанс пользователя сносится и перезапускается при следующей загрузке. Следовательно, загрузка или запуск из этого состояния занимает значительно больше времени, чем S1-S4. Полное завершение работы (S5) происходит при запросе перезагрузки системы или при вызове API завершения работы приложением.

Механическое состояние выключения: G3

В этом состоянии система полностью выключена и не потребляет питания. Система возвращается в рабочее состояние только после полной перезагрузки.

Поведение пробуждения по локальной сети

Функция пробуждения по локальной сети (WOL) выводит компьютер из состояния низкого энергопотребления, когда сетевой адаптер обнаруживает событие WOL (обычно это специально созданный пакет Ethernet).

WOL поддерживается в спящем режиме S3 или В спящем режиме S4 . Он не поддерживается в состояниях быстрого запуска или плавного выключения S5 . Сетевые адаптеры не вооружены для пробуждения в этих штатах, потому что пользователи не ожидают, что их системы проснутся самостоятельно.

WOL официально не поддерживается в состоянии мягкого выключения S5 . Однако BIOS в некоторых системах может поддерживать подключение сетевых адаптеров для пробуждения, даже если Windows не участвует в этом процессе.