Windows smm security mitigations table что это

Microsoft добавит новые меры безопасности UEFI в Windows 10 В прошлых публикациях, посвященных улучшениям безопасности Windows 10 [1,2,3,4], я неоднократно хвалил Microsoft за эти полезные нововведения. Новые механизмы безопасности помогают более эффективно бороться...

Microsoft добавит новые меры безопасности UEFI в Windows 10

В прошлых публикациях, посвященных улучшениям безопасности Windows 10 [1,2,3,4], я неоднократно хвалил Microsoft за эти полезные нововведения. Новые механизмы безопасности помогают более эффективно бороться с эксплойтами. Пока очевидно, что Microsoft все больше делает ставку на новые технологии защиты от эксплойтов, основанные на виртуализации Virtualization Based Security, при этом добавляя более современные метрики безопасности и вынося выполнение критических по безопасности операций в отдельные виртуальные машины с высоким уровнем привилегий.

На сей раз речь пойдет о безопасности прошивок UEFI. Известный гуру внутреннего устройства Windows Alex Ionescu опубликовал у себя в твиттере скриншот дополнительных требований безопасности UEFI, которые должны поддерживаться прошивками начиная с Windows 10 1703. Как известно, эта версия Windows 10 и может получить название очередного существенного обновления Redstone 2.

Не секрет, что сама прошивка, ее компоненты и драйверы в современных ПК являются почти мини-ОС, которая получает управление еще до передачи упropравления загрузчику Windows. Столь стремительное распространение UEFI подталкивает security-ресерчеров к детальному поиску уязвимостей в прошивках и их драйверах, а производителей BIOS/UEFI к пересмотру механизмов их защиты. Злоумышленнику достаточно воспользоваться уязвимостью только в одном компоненте прошивки, чтобы скомпрометировать такие продвинутые VBS- технологии защиты Windows 10 как Device Guard, Credential Guard, Windows Defender Application Guard.

Одним из подобных эксплойтов, который способен компрометировать все указанные выше технологии защиты Windows 10, основанные на виртуализации (VBS) является ThinkPwn, о котором я писал здесь. ThinkPwn использует уязвимость в драйвере прошивки для того, чтобы исполнить свой код на самом привилегированном уровне — SMM.


Рис. Абстрактные уровни привилегий исполнения кода. Высший относится к Intel ME, далее SMM и гипервизор. Компрометация UEFI-прошивки позволяет компрометировать гипервизор и основанные на нем механизмы защиты (Device Guard, Credential Guard, Windows Defender Application Guard).

Очевидно, что Microsoft учла вышеприведенные причины и добавила новые требования безопасности к прошивкам UEFI. Первое требование относится к фактической реализации DEP для прошивки. Т. е. страницы памяти с данными прошивки будут помечаться как NX (non-executable), что позволит исключить исполнение кода из ненадлежащих регионов памяти.

VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable.

Вторая функция безопасности относится к защите от эксплуатации уязвимостей, связанных с системной таблицей ACPI и драйверов (сервисов) UEFI. Для этого используется новая системная структура данных под названием Windows SMM Security Mitigations Table (WSMT).

The Windows SMM Security Mitigations Table (WSMT) specification contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.

Отметим, что в обоих случаях Microsoft подчеркивает, тот факт, что введенные методы безопасности обезопасят VBS от компрометации через уязвимости в прошивке.

Reduces the attack surface to VBS from system firmware

Источник

ACPI system description tables

Implementation of the Advanced Configuration and Power Interface (ACPI) Hardware Specification is not required on SoC-based platforms, but much of the ACPI Software Specification is (or can be) required. ACPI defines a generic, extensible table-passing mechanism, plus specific tables for describing the platform to the operating system.

Table structures and headers, including ID and checksum fields, are defined in the ACPI 5.0 specification. Windows utilizes this table-passing mechanism, in addition to the specific tables that are described in this article.

The idea behind these tables is to enable generic software to support standard intellectual property (IP) blocks that can be integrated into various platforms in diverse ways. With the table strategy, the platform-variable attributes of a particular platform are provided in a table, and used by generic software to adapt itself to the specific set of IP blocks integrated into the platform. This software can therefore be written once, thoroughly tested, and then optimized over time.

Root System Description Pointer (RSDP)

Windows depends on UEFI firmware to boot up the hardware platform. Hence, Windows will use the EFI system table to locate the RSDP, as described in section 5.2.5.2, «Finding the RSDP on UEFI Enabled Systems», of the ACPI 5.0 specification. The platform firmware fills in the address of either the RSDT or XSDT in the RSDP. (If both table addresses are provided, Windows will prefer the XSDT.)

Root System Description Table (RSDT)

The RSDT (or XSDT) includes pointers to any other system description tables provided on the platform. Specifically, this table contains pointers to the following:

The Fixed ACPI Hardware Table (FADT)

The multiple interrupt controller table (MADT)

Optionally, the Core System Resource Table (CSRT)

The Debug Port Table 2 (DBG2)

The Boot Graphics Resource Table (BGRT)

The Firmware Performance Data Table (FPDT)

The base system description table (DSDT)

Optionally, additional system description tables (SSDT)

Fixed ACPI Description Table (FADT)

The Fixed ACPI Hardware Table (FADT) contains important information about the various Fixed Hardware features available on the platform. To support hardware-reduced ACPI platforms, ACPI 5.0 extends the FADT table definition as follows:

The Flags field within the FADT (offset 112) has two new flags:

HARDWARE_REDUCED_ACPI Bit offset 20. Indicates that ACPI hardware is not available on this platform. This flag must be set if the ACPI Fixed Hardware Programming Model is not implemented.

LOW_POWER_S0_IDLE_CAPABLE Bit offset 21. Indicates that the platform supports low-power idle states within the ACPI S0 system power state that are more energy efficient than any Sx sleep state. If this flag is set, Windows will not try to sleep and resume, but will instead use platform idle states and connected standby.

The FADT Preferred_PM_Profile field (byte offset 45) has a new role entry, «Tablet». This role influences power management policy for the display and input, and affects the display of on-screen keyboards.

The «IA-PC Boot Architecture Flags» field (offset 109) has a new «CMOS RTC Not Present» flag (bit offset 5) to indicate that the PC’s CMOS RTC is either not implemented, or does not exist at the legacy addresses. If this flag is set, the platform must implement the ACPI Time and Alarm Control Method device. For more information, see the Control Method Time and Alarm device section in the ACPI defined devices topic.

New fields are added to support traditional PC sleep/resume on hardware-reduced ACPI platforms. These fields are ignored by Windows, but must be present in the table for compliance.

If the HARDWARE_REDUCED_ACPI flag is set, all fields relating to the ACPI Hardware Specification are ignored by the operating system.

All other FADT settings retain their meanings from the previous version, ACPI 4.0. For more information, see section 5.2.9, «Fixed ACPI Description Table (FADT)», of the ACPI 5.0 specification.

Multiple APIC Description Table (MADT)

In PC implementations of ACPI, the Multiple APIC Description Table (MADT) and PC-specific interrupt controller descriptors are used to describe the system interrupt model. For Arm-based SoC platforms, ACPI 5.0 adds descriptors for the Arm Holdings’ Generic Interrupt Controller (GIC) and GIC Distributor. Windows includes inbox support for the GIC and GIC Distributor. For more information about these descriptors, see sections 5.2.12.14, «GIC Structure», and 5.2.12.15, «GIC Distributor Structure», of the ACPI 5.0 specification.

The interrupt controller descriptor structures are listed immediately after the Flags field in the MADT. For Arm platforms, one descriptor is listed for each GIC, followed by one for each GIC Distributor. The GIC corresponding to the boot processor must be the first entry in the list of interrupt controller descriptors.

Generic Timer Description Table (GTDT)

As with the interrupt controller, there is a standard timer description table in ACPI. For Arm systems that utilize the GIT timer, ACPI’s GTDT can be used to leverage the built-in support for the GIT in Windows.

Core System Resources Table (CSRT)

Core System Resources (CSRs) are shared hardware functions such as interrupt controllers, timers and DMA controllers to which the operating system must serialize access. Where industry standards exist for features such as timers and interrupt controllers (on both x86 and Arm architectures), Windows builds in support for these features based on the standard tables described in ACPI (for example, MADT and GTDT). However, until the industry converges on DMA controller interface standards, there is a need to support some non-standard devices in the operating system.

Windows supports the concept of HAL extensions to address this issue. HAL extensions are SoC-specific modules, implemented as DLLs, that adapt the Windows HAL to a specific hardware interface of a specific class of CSR required by Windows. In order to identify and load these non-standard CSR modules, Microsoft has defined a new ACPI table. This table, which has a reserved signature of «CSRT» in the ACPI specification, must be included in the RSDT if non-standard CSRs are used on the platform.

The CSRT describes resource groups of CSRs, where each resource group identifies hardware of a particular type. Windows uses the identifier provided for the resource group to find and load the required HAL extension for this group. Resource groups within the CSRT might also contain individual resource descriptors, depending on the CSR type and the needs of the HAL extension. The format and use of these resource descriptors is defined by the HAL extension writer, who can make the extension much more portable and thereby support a variety of different SoC platforms simply by changing the resource descriptors contained in the CSRT.

To support maintenance of HAL extensions, and to manage the system resources used by these extensions, each resource group described in the CSRT must also be represented as a device within the platform’s ACPI namespace. For more information, see the following «Differentiated System Description Table (DSDT)» section. The device identifiers used in the resource group header must match the identifiers used in the device’s namespace node. For more information, see the Device Identification in ACPI section in the Device management namespace objects topic. The existence of these resource group namespace devices allows the HAL extension to be serviced by the Windows Update Service.

Debug Port Table 2 (DBG2)

Microsoft requires a debug port on all systems. To describe the debug port(s) built into a platform, Microsoft defines the Debug Port Table 2 (DBG2) for ACPI. This table specifies one or more independent port(s) for debugging purposes. The presence of the DBG2 table indicates that the platform includes at least one debug port. This table includes information about the identity and configuration of the debug port(s). The table is located in system memory with other ACPI tables, and must be referenced in the ACPI RSDT table.

Windows uses the Port Type value in the DBG2 table to identify and load the Kernel Debugger (KD) transport (for example, USB or serial) that the system requires. The KD transport then uses the Port Subtype value in the DBG2 table to identify the hardware interface used by the port. Other information in the DBG2 table specifies the system address of the port registers, which is used by the hardware interface module for the specified subtype. Finally, the DBG2 table must include a reference to the device node in the ACPI namespace that corresponds to the debug port. This reference enables Windows to manage conflicts between debugging use and normal use of the device, if any, and also to integrate the debugger with power transitions.

Differentiated System Description Table (DSDT)

In ACPI, peripheral devices and system hardware features on the platform are described in the Differentiated System Description Table (DSDT), which is loaded at boot, or in Secondary System Description Tables (SSDTs), which are loaded at boot or loaded dynamically at run time. For SoCs, the platform configuration is typically static, so the DSDT might be sufficient, although SSDTs can also be used to improve the modularity of the platform description.

ACPI defines an interpreted language (ACPI source language, or ASL) and an execution environment (ACPI virtual machine) for describing system devices and features, and their platform-specific controls, in an OS-agnostic way. ASL is used to define named objects in the ACPI namespace, and the Microsoft ASL compiler is used to produce ACPI machine language (AML) byte code for transmission to the operating system in the DSDT. The inbox Windows ACPI driver, Acpi.sys, implements the ACPI virtual machine and interprets the AML byte code. An AML object might simply return description information. Or, an AML object might be a method that performs computation or does I/O operations. A control method is an executable AML object that uses the operating system’s device drivers to do I/O operations on the platform hardware. ASL uses OpRegions to abstract the various address spaces accessible in the operating system. Control methods perform I/O operations as a series of transfers to and from named fields declared in OpRegions.

For more information about OpRegions, see section 5.5.2.4, «Access to Operation Regions», in the ACPI 5.0 specification. For more about ASL and control methods, see section 5.5, «ACPI Namespace», in the ACPI 5.0 specification.

Windows provides support for developing and debugging ASL code. The ASL compiler includes a disassembler to enable the implementer to load a namespace from a debugging target. The ASL compiler can then be used to reapply the namespace to the target for rapid prototyping and testing—without having to flash the system firmware. In addition, the Windows Kernel Debugger, in conjunction with a checked (CHK) version of the Acpi.sys driver, supports tracing and analyzing AML execution. For more information, see The AMLI Debugger.

Windows SMM Security Mitigations Table (WSMT)

The Windows SMM Security Mitigations Table (WSMT) specification contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.

This information applies to the following operating systems:

Windows ServerВ 2016

WindowsВ 10, version 1607

iSCSI Boot Firmware Table (iBFT)

The iSCSI Boot Firmware (iBF) Table (iBFT) is a block of information that contains various parameters that are useful to the iSCSI Boot process. The iBFT is the mechanism by which iBF parameter values are conveyed to the operating system. The iBF builds and fills in the iBFT. The iBFT is available to the Windows operating system to enable a consistent flow of the boot process.

Источник

title description ms.date

Fixed ComBuffer and Windows SMM Security Mitigation Table (WSMT)

Windows SMM Security Mitigation Table (WSMT) is a static table described in ACPI namespace that contains flags indicating that specific security features have been implemented.

08/18/2021

Fixed ComBuffer and Windows SMM Security Mitigation Table (WSMT)

Windows SMM Security Mitigation Table (WSMT) is a static table described in ACPI namespace that contains flags indicating that specific security features have been implemented on the system.

The Protection Flags field indicates the presence of specific BIOS security mitigations in the systems firmware. Supported versions of the Windows operating system read in the Windows SMM Security Table early during initialization, prior to start of the ACPI interpreter. Windows operating systems may elect to enable, disable, or de-feature certain security features based on the presence of these SMM Protections Flags.

Protection Flags FIXED_COMM_BUFFERS and COMM_BUFFER_NESTED_PTR_PROTECTION depend on the firmware vendor re-designing the System Management Interrupts (SMIs) to only read or write to an «allowed» list of regions that include MMIO and EFI-allocated memory.  It is not sufficient to check that pointers are outside of SMM, they must only be within these «safe» regions.  This prevents SMM from becoming a confused deputy which can bypass Windows flagship «Guard» features. The above-mentioned Protection Flags refer only to input validation and pointer checks and do NOT currently require enforcement via SMM page protections.

Support for the WSMT is included in the following versions of Windows:

  • Windows Server Technical Preview 2016

  • Windows 10, version 1607

  • Windows 10, version 1703

Related resources

Windows SMM Security Mitigations Table (WSMT) (DOCX download)

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

Ключевые слова: System Management Mode, System Management Interruption, средство защиты информации, компьютерная безопасность, регистр SMI_EN, кольца защиты, режим исполнения кода, архитектура x86.

Введение (Introduction)

Архитектура x86 подразумевает наличие как минимум трех различных уровней привилегий для выполнения инструкций процессором [1]. уровни привилегий называются кольцами защиты (англ. protection rings), где код, исполняемый в центральном кольце («ring 0»), обладает наибольшим доступом в операционной системе (ОС), а во внешнем кольце («ring 3») – наименьшим [Там же]. Эти уровни привилегий предназначены для реализации аппаратного разграничения доступа процесса к ресурсам ЭВМ (например, к портам ввода-вывода) и реализованы в ЭВМ в виде различных режимов работы центрального процессора (ЦП).

Однако, кроме стандартных уровней привилегий для ОС, существуют также более привилегированные уровни (обладающие большим доступом, чем «ring 0»), которые нумеруются в отрицательную область чисел, с соответствующими режимами работы ЦП [Там же]: «ring -1» – режим гипервизора и «ring -2» – System Management Mode (SMM) [1]. Также существует режим «ring -3», основанный на технологиях Intel Management Engine (ME) для процессоров Intel и AMD Secure Technology для процессоров AMD [2, 3]. В свою очередь режимы гипервизора и SMM подразумевают использование технологий гипервизора и SMM соответственно, в которых используется выделенная (недоступная из менее привилегированных режимов) память и независимое от ОС программное обеспечение (ПО): ядро, приложения и драйвера.

При этом уже в режиме супервизора (то есть на уровне «ring 0») исполняемые процессором инструкции обладают практически полным доступом к ресурсам ЭВМ, и этот доступ может контролироваться только более привилегированными режимами [1]. Вместе с этим выполнение инструкций в режимах «rings -1, -2, -3» для операционной системы (ОС) прозрачно и не отслеживаемо напрямую [4, 5]. Поэтому, с одной стороны, такие технологии являются ключевыми для атак низкого уровня [6, 7] и могут представлять угрозы для средств защиты информации (СЗИ), функционирующими с привилегиями не ниже «ring 0». А с другой стороны, с помощью таких технологий можно расширить функциональность существующих СЗИ, либо попытаться реализовать полнофункциональное СЗИ на основе таких технологий.

Используемые методы исследования (Research methods used)

В этой статье из ранее упомянутых режимов будет рассматриваться только SMM, и целью работы является оценка перспективы использования технологии SMM в разработке СЗИ. В работе используются такие методы исследования, как: анализ, абстрагирование, сравнение и эксперимент. Объектом исследования является SMM. Предмет исследования – возможность использования механизмов SMM для разработки СЗИ.

Обзор литературы (Literature review)

1. Описание SMM

System Management Mode (SMM) является привилегированным режимом выполнения кода у x86 совместимых процессоров (Intel, AMD), впервые реализованный компанией Intel в своих процессорах в середине 90-х годов [8]. С момента создания и до сих пор этот режим используется для совершения действий, которые были бы незаметны и практически не отслеживаемы для ОС, но при этом выполняемый код обладал полным доступом к памяти и всем подключенным устройствам [5].

Изначально SMM применялся в области управления питанием компонентов ЭВМ: обработчики событий в SMM собирали статистику по использованию устройств, и в случае долговременного простоя устройства отключались [8]. То есть первоначально в задачи SMM не входило решение проблем обеспечения безопасности, а привилегированный режим был обусловлен необходимостью в постоянном контроле всех устройств ЭВМ. На данный момент задача управление питанием компонентов ЭВМ не выполняется с помощью SMM, а выполняется при помощи ОС [Там же].

Для переключения процессора в SMM используются System Management Interruptions (SMIs), которые генерируются компонентами материнской платы, либо могут генерироваться различными драйверами, приложениями (в том числе приложениями из ОС) или пользователями с административными правами в ОС [5]. К типовым системным SMI, которые поддерживаются сейчас в большинстве ЭВМ (в частности, согласно документации, у компьютеров с 8/9/200/300 сериями чипсетов Intel [9–10 часть 12.8.3.7, 11–12 часть 5.2.4]), можно отнести следующие прерывания и соответствующие им события [5, 9–10 часть 12.8.3.7, 11–12 часть 5.2.4]:

  • GPIO Unlock SMI – генерируется при снятии бита Lock (GLE) с регистров управления выводами GPIO. Обработчик проверяет ПО, снявшее бит, и если оно не авторизованное, выставляет бит обратно;
  • TCO SMI – генерируется при различных событиях. Обработчик прерывания выполняет действия согласно источнику прерывания.
    • Прерывание генерируется Intel TCO watchdog-таймером обратного отсчета при опускании таймера до нуля. Этот таймер должен взводиться ОС каждый несколько секунд. Если таймер опустится до нуля, то будет вызвано прерывание, обработчик которого произведет перезагрузку системы.
    • Прерывание генерируется при выставление бита BIOSWE у регистра BIOS Control, отвечающий за возможность читать и писать в ПЗУ, где находится код BIOS’а. Если бит выставляется в SMM, то прерывание не будет сгенерировано, так как выполняемый код уже в SMM режиме; если бит выставляется в любом другом режиме, то прерывание будет сгенерировано, после чего будет вызван обработчик, который просто выставит бит обратно. Такой механизм реализован для защиты от перезаписи прошивки ЭВМ из любого режима кроме SMM.
  • APMC (APM Control) SMI – генерируется при записи в APM_CNT I/O порт (почти всегда это 0xB2 порт). Срабатывание такого прерывания может быть вызвано администратором ОС при помощи записи в ранее указанный порт. Количество обработчиков может быть 256, при этом при вызове можно указывать номер желаемого обработчика;
  • IOTR (IO Trap) SMI – генерируется при обращении к портам CPU I/O. Обработчик позволяют эмулировать Legacy устройства (например, клавиатуру), которые раньше использовали I/O порты;
  • xHCI (Extensible Host Controller Interface) SMI – генерируется USB-контроллером при различных событиях.
  • Periodic SMI – генерируется чипсетом по таймеру с периодичностью 8/16/32/64 (период настраивается с помощью битов PER_SMI_SEL).

2. SMM memory (SMRAM)

Для изолированности среды выполнения операций в режиме SMM используется память SMM memory (SMRAM), в которой хранятся все необходимые данные для работы SMM: код и обработчики прерываний, а также содержимое регистров (процессор сохраняет контекст при переключении в SMM). Если какая-либо операция выполняется не в режиме SMM, а в обычном режиме (менее привилегированном), то эта память недоступна, то есть нельзя как прочитать данные из этого пространства, так и записать в неё что-либо. SMRAM может состоять из следующих областей (вывод об использовании или не использовании сделан по отношению к современным ЭВМ со стандартной конфигурацией SMM) [5, 8]:

  • ASEG [0x000A0000-0x000BFFFF] – не используется,
  • HSEG [0xFEDA0000-0xFEDBFFFF] – не используется,
  • TSEG [настраиваемый диапазон] – используется.

3. Инициализация SMRAM

Целесообразно рассматривать инициализацию SMRAM и работу SMM с использованием UEFI BIOS, а не Legacy BIOS, так как большинство современных ЭВМ используют именно UEFI интерфейс, а Intel вовсе планирует исключить поддержку Legacy BIOS из своих устройств в ближайшие годы [13].

Весь код SMM (в том числе SMI обработчики) хранится в коде UEFI BIOS, который находится в ПЗУ. Этот код выгружается в SMRAM и конфигурируется однократно при включении ЭВМ на стадии SMM, которая в свою очередь является частью фазы DXE (все стадии изображены на рисунке 1) [14]. После чего SMM фаза активна в течение всего временного интервала активности ЭВМ параллельно другим Run Time (RT) фазам.

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

1.png 

Рисунок 1. Фазы загрузки системы с UEFI

4. Регистры SMM

Для корректной работы SMRAM и настройки доступа к этой памяти используется несколько регистров. Важнейшим и основным регистром является System Management RAM Control (SMRAMC) регистр [15 часть 3.29]. Значение SMRAMC выставляется при инициализации SMRAM, после чего регистр блокируется до следующего рестарта ЭВМ [16]. Среди битов этого регистра наиболее важны биты D_OPEN и D_LCK, которые должны быть установлены в 0 и 1 соответственно на любой корректно сконфигурированной системе, чтобы SMRAM память была доступна только из кода, выполняемого в SMM.

Также существуют производные регистры для обеспечения корректного доступа к памяти, которые были созданы вследствие обнаружения различных векторов атак на SMM (эти регистры также должны быть корректно сконфигурированы и заблокированы аппаратным обеспечением):

  • System Management Range Registers (SMRR) – определяет области памяти, в которые запись не из SMM игнорируется, а тип памяти является некэшируемым. Должен быть корректно выставлен вендорами. Атака: SMM cache poisoning [17]
  • TSEGMB регистр у DMA-контроллеров – дублирует информацию о местоположение TSEG, после чего запрещается писать в эту область с помощью DMA. Должен быть корректно выставлен вендорами. Атака: DMA атака [18];
  • SMI_LOCK бит регистра General PM Configuration, SMM_BWP бит регистра BIOS Control – отвечают за генерацию SMI при прошивании Атака: отключение генерации SMI, после чего перепрошивка BIOS неавторизованным ПО [19].

Результаты (Results)

1. Функции безопасности с использованием SMM

SMM предназначен для обработки прерываний, которые сгенерированы либо системой (системные SMI), либо прошивкой / драйверами / приложениями, обладающими доступом с правами администратора в ОС (программные SMI) при помощи записи в APM_CNT I/O порт. Таким образом, возможно создание лишь двух типов функции (обработчиков SMI) на основе SMM:

  1. Создание обработчика программных SMI. Вызывать такой обработчик можно с помощью ПО в ОС.
  2. Расширение обработчика системных SMI. Вызываться такой обработчик будет автоматически при каких-то событиях (зависит от типа SMI).

При этом, учитывая особенности SMM (привилегированность, изолированность среды выполнения инструкций SMM, хранение кода SMM в BIOS), можно говорить о применение обработчиков SMI для создания функций, которым необходимо одно из свойств:

  • выполнение привилегированных инструкций;
  • выполнение инструкций в изолированной среде по отношению к программной среде в ОС;
  • возможность хранения секретных данных малого размера (например, токены, сертификаты, криптографические ключи) в защищенном пространстве, то есть использование части памяти ПЗУ, где хранится код BIOS, как небольшое хранилище информации, к которому можно получить доступ с помощью SMI обработчиков.

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

1.1. Создание обработчика программных SMI

Для вызова обработчика программных SMI необходим корректно выставленный бит APMC_EN регистра SMI_EN [9–10 часть 12.8.3.7, 11–12 часть 5.2.4]. Этот бит является R/W и может быть перезаписан в любой момент, если не реализована функциональность блокировки регистра SMI_EN. Таким образом, не следует полагаться на гарантированное срабатывание прерывания из-за отсутствия встроенной функциональности блокировки.

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

  • выполнение мгновенной перезагрузки/выключения системы при выявленных попытках несанкционированного доступа;
  • проверка переданных учетных данных и расширение прав доступа пользователя;
  • генерация дочерних сертификатов/ключей на основе корневого сертификата/ключа без возможности прочитать корневой сертификат/ключ;
  • включение/отключение/проверка компонентов системы и периферийных устройств (например, проверка контрольной суммы кода BIOS или отключение одного из USB устройств через xHCI интерфейс);
  • настройка регистров, которые контролируют доступ к компонентам системы и периферийным устройствам (например, включение/выключение возможности записи на жесткий диск).

1.2. Расширение обработчика системных SMI

Для вызова обработчика системных SMI необходим корректно выставленный бит включения прерываний регистра SMI_EN для требуемого типа прерываний [9–10 часть 12.8.3.7, 11–12 часть 5.2.4]. Большинство таких битов являются R/W и, аналогично биту APMC_EN, могут быть перезаписаны в любой момент, если отсутствует функциональность блокировки регистра SMI_EN. Таким образом, подобно программным SMI, нельзя полагаться на гарантированное срабатывание большинства системных SMI при отсутствии функциональности блокировки. Но для некоторых прерываний предусмотрена встроенная функциональность блокировки соответствующего бита, так, например, для всех современных ЭВМ x86 архитектуры такими битами являются: GPIO_UNLOCK_SMI_EN и TCO_EN.

На базе таких обработчиков можно реализовать более специфичные функции с автоматически генерируемыми прерываниями различными компонентами системы при наступлении конкретных событий (зависит от компонента и типа SMI). Примеры возможных функций безопасности:

  • обработчик TCO SMI можно модифицировать для обработки запросов на перезапись прошивки;
  • обработчик GPIO Unlock SMI можно модифицировать, либо вовсе заменить своим обработчиком для контроля доступа ОС к GPIO-контактам;
  • обработчик xHCI SMI (xHCI_SMI_EN бит является R/W) можно модифицировать, либо дополнить необходимыми функциями, чтобы обрабатывать различные события, связанные с USB устройствами [20 часть 4.22.1];
  • обработчик Periodic SMI (PERIODIC_EN бит является R/W) можно модифицировать, либо дополнить необходимыми функциями, чтобы выполнять указанный код многократно с установленным периодом.

2. Плюсы и минусы SMM для СЗИ

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

2.1. Плюсы SMM

Фундаментальные

  • Привилегированный доступ.

В базовом сценарии SMM предоставляет максимальный доступ к системе среди прочих встроенных в систему технологий (за исключением технологий, которые базируются на РКБ).

  • Дешевизна и высокая бесперебойность.

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

Технические

  • Ранняя стадия старта функционирования.

SMM код загружается и запускается в DXE фазе загрузки UEFI. Это фаза идет после фаз SEC и PEI, и до фазы Boot Device Selection (BDS) (см. рисунок 1) [21]. И с одной стороны, наличие двух фаз перед запуском SMM является, определенно, минусом, но с другой стороны это позволяет коду SMM работать с памятью (которая инициализируется в PEI) и работать с устройствами системы. При этом полноценно функционировать SMM начинает после блокирования SMRAM, до окончания фазы DXE, то есть в конце фазы DXE SMRAM уже находится в заблокированном состояние, и SMM может обрабатывать приходящие запросы. Поэтому в фазе BDS можно говорить о полном функционировании технологии SMM.

  • Встроенная защита кода SMM от перезаписи.

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

2.2. Минусы SMM

Фундаментальные

  • Доверие к вендору.

При использовании SMM необходим РКБ для построения доверенной системы (в том числе для того, чтобы контролировать недоверенный процессор [22]), либо необходимо доверять процессору (который в таком случае будет выполнять некоторые задачи РКБ) и, как следствие, доверять вендору. Также, поскольку системные SMI генерируется различными компонентами системы (например, xHCI контроллером, отвечающий за взаимодействие с USB), необходимо доверять этим контроллерам в части срабатывания прерываний при наступлении конкретных событий.

Технические

  • Платформозависимость.

Технология SMM сильно платформозависима и разработана только для x86 архитектуры. Также не менее важным является факт, что вендоры (в том числе Intel, AMD) не гарантируют наличие тех или иных системных SMI в системе по умолчанию (это можно проследить в документации [9–10 часть 12.8.3.7, 11–12 часть 5.2.4]).

  • Ограничения по памяти.

Согласное документации под сегмент TSEG SMRAM может быть выделено 1, 2 или 8 MB (мегабайт) [16 часть 3.37], что ставит ограничения на разрабатываемый код.

  • Большинство битов в регистре SMI_EN являются R/W.

Поскольку большинство битов в регистре SMI_EN является R/W, нельзя полагаться на срабатывание конкретных SMI. Для устранения этого недостатка требуется разработать собственную логику в SMM, которая сможет блокировать необходимый бит.

Обсуждение (Discussions)

Таким образом, наиболее целесообразным и простым использованием SMM является применение этой технологии для реализации небольшого хранилища данных, либо функций, к которым будет ограничен доступ на чтение и изменение посредством SMI обработчиков. При этом обеспечить взаимодействие с этой частью памяти и получать доступ к ней можно напрямую из ОС. Примеров реализации коммуникации кода ОС и SMM кода в свободном доступе достаточно много [14, 23, 24].

С другой стороны, можно использовать автоматически генерируемые SMI, создаваемые Platform Controller Hub’ом (PCH). Но этот способ является эффективным только в случае блокировки битов, отвечающих за срабатывание прерываний, поэтому необходимо также реализовать дополнительную функциональность, которая будет отвечать за неизменность этих битов. Документация Intel не декларирует возможностей по блокировке таких битов [9–10 часть 12.8.3.7, 11–12 часть 5.2.4], а примеры атак на ЭВМ [25] с изменением таких битов еще раз подтверждают наличие векторов атак в случае реализации СЗИ через SMI. Однако существует патент по реализации блокировки регистра SMI_EN (см. [26]), но он скорее описывает архитектурную возможность по аппаратному улучшению чипсета (в частности, южного моста чипсета), нежели возможность по реализации блокировки регистра с помощью программных средств. Таким образом, предлагаемый вариант блокировки в патенте может быть целесообразен для вендоров компьютерной техники, поскольку они могут вносить существенные изменения в структуру элементов ЭВМ, но не является целесообразным для разработчиков СЗИ.

Заключение (Conclusions)

Из изложенных выше выкладок можно сделать вывод, что поскольку выполняемый в SMM код обладает достаточно привилегированным доступом в ЭВМ, этот режим остается крайне интересен для исследования на уязвимости с целью выработки рекомендаций по корректному конфигурированию. При этом из-за архитектурных особенностей данной технологии, реализация каких-либо новых инструментов безопасности с использованием SMM представляет собой сложную и нецелесообразную задачу. Поэтому в современных ЭВМ необходимо правильно конфигурировать SMM, и не следует полагаться на эту технологию при разработке СЗИ.

Литература (References)

  1. Domas C. The Memory Sinkhole // Официальный сайт конференции Black Hat [Электронный ресурс]. URL: https://www.blackhat.com/docs/us-15/materials/us-15-Domas-The-Memory-Sinkhole-Unleashing-An-x86-Design-Flaw-Allowing-Universal-Privilege-Escalation-wp.pdf (дата обращения: 14.11.2020).
  2. Oster J. E. Getting Started with Intel® Active Management Technology (Intel® AMT) // Официальный сайт компании Intel [Электронный ресурс]. URL: https://software.intel.com/content/www/us/en/develop/articles/getting-started-with-intel-active-management-technology-amt.html (дата обращения: 18.11.2020).
  3. О безопасности UEFI, часть заключительная [Электронный ресурс]. URL: https://habr.com/ru/post/268423/ (дата обращения: 18.11.2020).
  4. Jiewen Y., Zimmer J. V. A Tour Beyond BIOS Launching STM to Monitor SMM in EDK II // Официальный сайт компании Intel [Электронный ресурс]. URL: https://software.intel.com/content/dam/develop/external/us/en/documents/a-tour-beyond-bios-launching-stm-to-monitor-smm-in-efi-developer-kit-ii-819978.pdf (дата обращения: 18.11.2020).
  5. О безопасности UEFI, часть вторая [Электронный ресурс]. URL: https://habr.com/ru/post/267197/ (дата обращения: 18.11.2020).
  6. Rauchberger J., Luh R., Schrittwieser S. LONGKIT – A Universal Framework for BIOS/UEFI Rootkits in System Management Mode // Conference: 3rd International Conference on Information Systems Security and Privacy. P. 346–353.
  7. Банк данных угроз безопасности информации. SMM // Официальный сайт ФСТЭК [Электронный ресурс]. URL: https://bdu.fstec.ru/search?q=SMM (дата обращения: 18.11.2020).
  8. SMM и SMRAM или 128 Кб потусторонней памяти: исследовательская работа №5 [Электронный ресурс]. URL: https://xakep.ru/2008/07/29/44663/ (дата обращения: 18.11.2020).
  9. Intel® 8 Series/C220 Series Chipset Family Platform Controller Hub (PCH) // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/8-series-chipset-pch-datasheet.pdf (дата обращения: 18.11.2020).
  10. Intel® 9 Series Chipset Family Platform Controller Hub (PCH) // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/9-series-chipset-pch-datasheet.pdf (дата обращения: 18.11.2020).
  11. Intel® 200 (Including X299) and Intel® Z370 Series Chipset Families Platform Controller Hub (PCH). Volume 2 // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/200-series-chipset-pch-datasheet-vol-2.pdf (дата обращения: 18.11.2020).
  12. Intel® 300 Series and Intel® C240 Series Chipset Families Platform Controller Hub (PCH). Volume 2 // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/300-series-chipset-pch-datasheet-vol-2.pdf (дата обращения: 18.11.2020).
  13. Intel to Remove Legacy BIOS Support from UEFI by 2020 [Электронный ресурс]. URL: https://www.anandtech.com/show/12068/intel-to-remove-bios-support-from-uefi-by-2020 (дата обращения: 09.05.2021).
  14. Building reliable SMM backdoor for UEFI based platforms [Электронный ресурс]. URL: http://blog.cr4.sh/2015/07/building-reliable-smm-backdoor-for-uefi.html (дата обращения: 18.11.2020).
  15. 8th and 9th Generation Intel® Core™ Processor Families and Intel® Xeon E Processor Family // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/8th-gen-core-family-datasheet-vol-2.pdf (дата обращения: 18.11.2020).
  16. Intel® Platform Innovation Framework for EFI System Management Mode Core Interface Specification (SMM CIS) // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.ru/content/dam/doc/reference-guide/efi-smm-cis-v091.pdf (дата обращения: 18.11.2020).
  17. Attacking SMM Memory via Intel® CPU Cache Poisoning [Электронный ресурс]. URL: https://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf (дата обращения: 18.11.2020).
  18. Attacking UEFI Boot Script [Электронный ресурс]. URL: https://bromiumlabs.files.wordpress.com/2015/01/venamis_whitepaper.pdf (дата обращения: 18.11.2020).
  19. О безопасности UEFI, части нулевая и первая [Электронный ресурс]. URL: https://habr.com/ru/post/266935/ (дата обращения: 18.11.2020).
  20. eXtensible Host Controller Interface for Universal Serial Bus (xHCI) // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf (дата обращения: 18.11.2020).
  21. Устройство файла UEFI BIOS, часть полуторная: UEFI Platform Initialization [Электронный ресурс]. URL: https://habr.com/ru/post/185764/ (дата обращения: 18.11.2020).
  22. Елькин В. М. Контроль недоверенного процессора // Комплексная защита информации: материалы XXIII научно-практической конференции, Суздаль, 22–24 мая 2018 г. М.: Медиа Групп «Авангард», 2018. С. 209–211.
  23. System Management Mode Hacks [Электронный ресурс]. URL: http://phrack.org/issues/65/7.html (дата обращения: 18.11.2020).
  24. Использование Intel Processor Trace для трассировки кода System Management Mode [Электронный ресурс]. URL: https://habr.com/ru/company/dsec/blog/481692/ (дата обращения: 18.11.2020).
  25. Advanced x86: Introduction to BIOS & SMM. SMI Suppression [Электронный ресурс]. URL: https://opensecuritytraining.info/IntroBIOS.html (дата обращения: 18.11.2020).
  26. Ziarnik G. P., Durham M. R., Piwonka M. A. Pattern № US9483426B2, United States (US). Locking a system management interrupt (SMI) enable register of a chipset. Appl. № US14/364,706; PCT Filed 31.01.2012; PCT № PCT/US2012/023225; PCT Date 12.06.2014;

Автор: Пахомов М. В.

Дата публикации: 20.12.2021

Библиографическая ссылка: Пахомов М. В. Технология SMM и ее применение в компьютерной безопасности // Вопросы защиты информации. М., 2021. № 4. С. 13–19.


Содержание

  1. Microsoft добавит новые меры безопасности UEFI в Windows 10
  2. Безопасность запуска system Guard и защита SMM System Guard Secure Launch and SMM protection
  3. Как включить безопасный запуск System Guard How to enable System Guard Secure Launch
  4. Управление мобильными устройствами Mobile Device Management
  5. Групповая политика Group Policy
  6. Центр обеспечения безопасности Windows Windows Security Center
  7. Реестр Registry
  8. Настройка и запуск system Guard Secure Launch How to verify System Guard Secure Launch is configured and running
  9. Understanding the Windows SMM Security Mitigation Table (WSMT)
  10. Background
  11. Implications of the WSMT on Windows VBS Support
  12. Implementation Notes
  13. Validating the WSMT Protections
  14. Supported versions of Windows
  15. О безопасности UEFI, часть вторая
  16. Часть вторая. SMM
  17. Заключение
  18. Настройка защиты от эксплойтов Customize exploit protection
  19. Использование смягчения защиты Exploit protection mitigations
  20. Настройка системных смягчений с помощью приложения Безопасности Windows Configure system-level mitigations with the Windows Security app
  21. Справка PowerShell PowerShell reference
  22. Справочная таблица PowerShell PowerShell reference table
  23. Настройка уведомления Customize the notification
  24. Видео

Microsoft добавит новые меры безопасности UEFI в Windows 10

Windows smm security mitigations table что этоВ прошлых публикациях, посвященных улучшениям безопасности Windows 10 [1,2,3,4], я неоднократно хвалил Microsoft за эти полезные нововведения. Новые механизмы безопасности помогают более эффективно бороться с эксплойтами. Пока очевидно, что Microsoft все больше делает ставку на новые технологии защиты от эксплойтов, основанные на виртуализации Virtualization Based Security, при этом добавляя более современные метрики безопасности и вынося выполнение критических по безопасности операций в отдельные виртуальные машины с высоким уровнем привилегий.

На сей раз речь пойдет о безопасности прошивок UEFI. Известный гуру внутреннего устройства Windows Alex Ionescu опубликовал у себя в твиттере скриншот дополнительных требований безопасности UEFI, которые должны поддерживаться прошивками начиная с Windows 10 1703. Как известно, эта версия Windows 10 и может получить название очередного существенного обновления Redstone 2.

Не секрет, что сама прошивка, ее компоненты и драйверы в современных ПК являются почти мини-ОС, которая получает управление еще до передачи упropравления загрузчику Windows. Столь стремительное распространение UEFI подталкивает security-ресерчеров к детальному поиску уязвимостей в прошивках и их драйверах, а производителей BIOS/UEFI к пересмотру механизмов их защиты. Злоумышленнику достаточно воспользоваться уязвимостью только в одном компоненте прошивки, чтобы скомпрометировать такие продвинутые VBS- технологии защиты Windows 10 как Device Guard, Credential Guard, Windows Defender Application Guard.

Одним из подобных эксплойтов, который способен компрометировать все указанные выше технологии защиты Windows 10, основанные на виртуализации (VBS) является ThinkPwn, о котором я писал здесь. ThinkPwn использует уязвимость в драйвере прошивки для того, чтобы исполнить свой код на самом привилегированном уровне — SMM.

Windows smm security mitigations table что это
Рис. Абстрактные уровни привилегий исполнения кода. Высший относится к Intel ME, далее SMM и гипервизор. Компрометация UEFI-прошивки позволяет компрометировать гипервизор и основанные на нем механизмы защиты (Device Guard, Credential Guard, Windows Defender Application Guard).

Очевидно, что Microsoft учла вышеприведенные причины и добавила новые требования безопасности к прошивкам UEFI. Первое требование относится к фактической реализации DEP для прошивки. Т. е. страницы памяти с данными прошивки будут помечаться как NX (non-executable), что позволит исключить исполнение кода из ненадлежащих регионов памяти.

VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable.

Вторая функция безопасности относится к защите от эксплуатации уязвимостей, связанных с системной таблицей ACPI и драйверов (сервисов) UEFI. Для этого используется новая системная структура данных под названием Windows SMM Security Mitigations Table (WSMT).

The Windows SMM Security Mitigations Table (WSMT) specification contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.

Отметим, что в обоих случаях Microsoft подчеркивает, тот факт, что введенные методы безопасности обезопасят VBS от компрометации через уязвимости в прошивке.

Reduces the attack surface to VBS from system firmware

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.

Источник

Безопасность запуска system Guard и защита SMM System Guard Secure Launch and SMM protection

В этом разделе рассказывается о настройке системной охраны безопасного запуска и системы управления режимом (SMM), чтобы повысить безопасность запуска устройств Windows 10. This topic explains how to configure System Guard Secure Launch and System Management Mode (SMM) protection to improve the startup security of Windows 10 devices. Сведения ниже представлены с клиентской точки зрения. The information below is presented from a client perspective.

Как включить безопасный запуск System Guard How to enable System Guard Secure Launch

Вы можете включить безопасный запуск System Guard с помощью любого из этих параметров: You can enable System Guard Secure Launch by using any of these options:

Управление мобильными устройствами Mobile Device Management

Безопасный запуск System Guard можно настроить для управления мобильными устройствами (MDM) с помощью политик DeviceGuard в CSP политики, в частности DeviceGuard/ConfigureSystemGuardLaunch. System Guard Secure Launch can be configured for Mobile Device Management (MDM) by using DeviceGuard policies in the Policy CSP, specifically DeviceGuard/ConfigureSystemGuardLaunch.

Групповая политика Group Policy

Нажмите кнопку Начните > и нажмите кнопку Изменить групповую политику. Click Start > type and then click Edit group policy.

Нажмите кнопку Настройка > компьютерной конфигурации Административные шаблоны > **** > Системный охранник устройства > включив конфигурациюбезопасного запуска на основе виртуализации. > **** Click Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security > Secure Launch Configuration.

Windows smm security mitigations table что это

Центр обеспечения безопасности Windows Windows Security Center

Нажмите **** > кнопку Начнитеобновление > параметров & безопасностиWindows Security Open Windows Security Device Security Core > **** > **** > **** > isolation > Firmware protection. Click Start > Settings > Update & Security > Windows Security > Open Windows Security > Device security > Core isolation > Firmware protection.

Windows smm security mitigations table что это

Реестр Registry

Редактор Open Registry. Open Registry editor.

Щелкните HKEY_LOCAL_MACHINE > system > CurrentControlSet > Control > DeviceGuard > Scenarios. Click HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > DeviceGuard > Scenarios.

Щелкните правой кнопкой мыши Сценарии > New > Key и назови новый ключ SystemGuard. Right-click Scenarios > New > Key and name the new key SystemGuard.

Щелкните правой кнопкой мыши SystemGuard > Новое > значение DWORD (32-bit) и назови новое включенное значение DWORD. **** Right-click SystemGuard > New > DWORD (32-bit) Value and name the new DWORD Enabled.

Дважды щелкните Включено, измените значение до 1и нажмите кнопку ОК. Double-click Enabled, change the value to 1, and click OK.

Windows smm security mitigations table что это

Настройка и запуск system Guard Secure Launch How to verify System Guard Secure Launch is configured and running

Чтобы убедиться, что безопасный запуск запущен, используйте системную информацию (MSInfo32). To verify that Secure Launch is running, use System Information (MSInfo32). Нажмите кнопку Начните, ищите **** сведения о системе и посмотрите в статье Настройка служб безопасности на основе виртуализации и служб безопасности на основе виртуализации. **** Click Start, search for System Information, and look under Virtualization-based Security Services Running and Virtualization-based Security Services Configured.

Windows smm security mitigations table что это

Чтобы включить запуск System Guard Secure, платформа должна соответствовать всем базовым требованиям для device Guard, Credential Guardи Безопасности на основе виртуализации. To enable System Guard Secure launch, the platform must meet all the baseline requirements for Device Guard, Credential Guard, and Virtualization Based Security.

Источник

Understanding the Windows SMM Security Mitigation Table (WSMT)

The Windows SMM Security Mitigation Table (WSMT) is an ACPI table defined by Microsoft that allows system firmware to confirm to the operating system that certain security best practices have been implemented in System Management Mode (SMM) software. The WSMT table definition is described in the Windows SMM Security Mitigations Table (WMST) specification.

Background

The WSMT was defined to better support Windows Virtualization-based Security features. Please refer to Virtualization-based Security (VBS) for more background on VBS. Because SMM operates without the operating system’s knowledge or control, SMM represents a significant attack surface that could be leveraged by malicious code to compromise or circumvent the OS protections enabled through VBS. Delivering a robust and secure VBS platform requires careful scrutiny and likely updates of SMM code by the OEM to eliminate common vulnerabilities that may be exploited. The WSMT contains flags which firmware can set to indicate to the operating system which of these specific security best practices have been implemented.

Implications of the WSMT on Windows VBS Support

The WSMT Protection Flags field indicates the presence of these specific SMM security mitigations in the systems firmware. Supported versions of the Windows operating system read the WSMT Protection Flags early during initialization, prior to hypervisor and VBS launch, and may elect to enable, disable, or de-feature certain security features based on the presence of these SMM Protections Flags.

Implementation Notes

Proper implementation of the security mitigations represented by the WSMT Protection Flags FIXED_COMM_BUFFERS and COMM_BUFFER_NESTED_PTR_PROTECTION will require the firmware vendor carefully evaluate and possibly re-design the System Management Interrupt (SMI) handlers. All SMI handlers must be restricted to only access (read or write) to allowable memory regions that contain MMIO and EFI-allocated memory. It is not sufficient to check that pointers in SMM do not reference memory entirely outside of SMM. Rather, all SMM pointers must be validated to be within these safe memory regions. This prevents SMM from being exploited in a «confused deputy» attack, which could then be leveraged to compromise Windows VBS features. The above-mentioned Protection Flags refer only to input validation and pointer checks and do NOT currently require enforcement via SMM page protections. For example, SMM should not read or write to memory that was described by the firmware as EfiConventionalMemory because it may contain secrets or cause software to behave unpredictably.

Validating the WSMT Protections

Because SMM is opaque to the operating system, it is not possible to produce a test which runs in Windows to verify that the protections prescribed in the WSMT specification are actually implemented in SMM. From the operating system, the only check that is possible is to look for the presence of the WSMT, and check the state of all defined Protection Flags.

Therefore, it is the responsibility of the OEM to carefully scrutinize each system’s SMM code and ensure that firmware complies with the guidance outlined in the WSMT specification and this article. No Protection Flag should be set to «true» until the OEM has confirmed that the mitigations corresponding to each Protection Flag value have been properly implemented. Failing to adhere to this as a best practice will leave the platform vulnerable to compromise, and negate the effectiveness of multiple OS protections and Windows security features which rely on VBS to maintain robust security boundaries.

Supported versions of Windows

Support for the WSMT is included in the following versions of Windows:

Источник

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

Часть вторая. SMM

Немножечко ликбеза
Аппаратное SMI

Писать про него особенно нечего: подаем напряжение на ногу — имеем прерывание. Сейчас используется редко, т.к. почти на всех системах теперь имеются мультифункциональные GPIO, которые могут генерировать события, не прерывая работу ОС, плюс не нужна дополнительная логика для определения, кто же конкретно сгенерировал аппаратное SMI, ведь устройств много, а нога — одна.

Системные SMI
Программные SMI

Программные SMI генерируются чаще всего либо прошивкой, либо драйверами, но ничего не мешает атакующему с правами администратора в ОС (точнее, необходимы права на исполнение инструкции out) тоже генерировать их.
Программное SMI генерируется при записи в CPU IO-порт APM_CNT (чаще всего это порт 0xB2), в качестве параметра в регистре AL передается его номер. Таким образом, максимальное количество различных обработчиков программных SMI в системе — 256, но реально их от 0-5 на специализированных системах, подготовленных для работы с RTOS, до 15-20 на системах с кучей разного железа, которым надо управлять без вмешательства ОС.

Как реализован SMM

Для кода SMM-диспетчера и обработчиков SMI выделяется 1-3 области физической памяти, которую во всех «обычных» режимах исполнения чипсет помечает как область MMIO с несуществующим устройством, т.е. для всего остального мира эти области — сплошная череда 0xFF, которые невозможно перезаписать. Первая область, называемая обычно ASEG (т.е. «сегмент А»), предназначена для т.н. legacy SMM code, т.е. старых 16-битных обработчиков SMI, которых на современных системах уже нет. Имя сегменту досталось за то, что он находится по фиксированным физическим адресам 0xA0000 — 0xBFFFF. Вторая область с фиксированными адресами — HSEG (т.е. «высокий сегмент»), раньше находилась на 0xFEDA0000 — 0xFEDBFFFF, но на современных системах не используется, т.к. имеется гораздо более удобный сегмент с настраиваемыми адресом и размером — TSEG (т.е. «топовый сегмент»), в котором и находятся сейчас 99% кода, исполняемого в SMM, а в ASEG остается только небольшая заглушка для совместимости.
При переходе в SMM процессор сохраняет практически весь контекст (т.е. содержимое практически всех регистров, какие именно не сохраняются — зависит от конкретной микроархитектуры), причем к сохраненному контексту у обработчиков SMI есть полный доступ, и потому он может общаться с системой через изменение сохраненных значений.
Для ОС вызов SMM кода выглядит как волшебное изменение содержимого регистров и памяти, и хотя отследить длительность нахождения в SMM все же можно по косвенным признакам, а факт перехода в него — по непосредственным, при помощи чтения регистра MSR_SMI_COUNT до и после вызова инициации программного прерывания, но повлиять на длительность обработчика SMI ОС не может, поэтому SMM плохо совместим с hard-RTOS (стоит отметить, что вся архитектура x86 совместима с ними весьма через раз, но это другая история).
При настройках по умолчанию работающий в SMM код имеет полный доступ ко всей физической памяти на чтение и запись, полный доступ ко всем подключенным устройствам, в общем — может практически все, и при этом независим от ОС и недоступен из нее даже на чтение, что сильно затрудняет его анализ и делает код обработчиков SMI весьма привлекательной целью для атаки. Более того, если атакуемой системе доступна из SMM запись на SPI-микросхему (а она доступна во всех случаях, кроме систем с включенной PFAT, которые не найти с огнем, систем с Read-only BIOS’ом, которые встречаются еще реже, и систем с защитой через PR-регистры), то успешная атака может закончиться записью своего кода в BIOS, с последующем воровством, убийством и непотребством с гусями. Именно поэтому защитить SMM от вставки туда вредоносного кода — жизненно необходимо.

Атаки на SMM и защита от них
Забытый D_LOCK

Код в SMRAM не появляется там самостоятельно, сначала саму SMRAM нужно настроить, инициализировать физическую память, настроить TSEG так, чтобы все обработчики туда влезли, скопировать туда код SMM-диспетчера и обработчиков, настроить там таблицы дескрипторов — в общем, навести строгий уставной порядок, после чего обязательно снять бит D_OPEN, чтобы никто больше там ничего не испортил, и установить бит D_LOCK, чтобы D_OPEN нельзя было поставить назад. На некоторых старых системах установить D_LOCK забывали, и там SMM был отрыт всем ветрам, но во времена UEFI этого уже не происходит, так что этот вектор атаки ушел в историю.

SMM cache poisoning

Еще одна историческая атака — отравление кэша SMRAM, которую в 2009 году опубликовали Rafal Wojtczuk и Joanna Rutkowska. Суть атаки коротко — меняем тип памяти для региона SMRAM на Write-Back, организуем запись в регион SMRAM своего кода, запись в память не происходит, но при этом наш код остается в кэше второго уровня, после чего генерируем программное SMI и процессор читает данные не из SMRAM, а из кэша, и выполняет наш вредоносный код. Проблема решилась радикально — производители CPU запретили ставить режим WB на SMRAM, и потому системе с UEFI этой уязвимости не подвержены.

SMM call-out, она же SMM incursion attack

Please, please, please, go apply patches!

DMA attack
SMM cross-buffer attack

Представленная специалистами из Intel ATR атака на обработчики SMI, которые принимают в качестве параметра указатель и размер буфера, и производят запись в него. Атакующий может передать указатель и размер таким образом, чтобы буфер пересекал границу RAM-SMRAM, а т.к. обработчик SMI имеет доступ к SMRAM, то он перепишет какую-то часть данных вначале SMRAM. При удачном стечении обстоятельств (т.е. приблизительно после 500 часов отладки минимум) обработчик может переписать служебные структуры диспетчера SMM или других обработчиков нужным атакующему образом, и он получит возможность выполнения произвольного SMM-кода. Атака адски сложная и целевая, но вполне возможная, поэтому с начала 2015 года все обработчики SMI, принимающие указатели на буфер, обязаны валидировать его перед использованием. На более старых системах атака будет работать, но вероятность того, что именно вас через нее взломают — невелика.

Заключение

Ну вот, теперь разобрались более или менее и с SMM, в следующей части поговорим об атаках на S3 BootScript.
Спасибо за внимание, безопасных вам прошивок.

Источник

Настройка защиты от эксплойтов Customize exploit protection

Область применения: Applies to:

Хотите испытать Defender для конечной точки? Want to experience Defender for Endpoint? Зарегистрився для бесплатной пробной. Sign up for a free trial.

Защита от эксплойтов автоматически применяет ряд методов смягчения последствий эксплойта как в операционных системах, так и в отдельных приложениях. Exploit protection automatically applies a number of exploit mitigation techniques on both the operating system processes and on individual apps.

Настройка этих параметров с помощью приложения Windows Security на отдельном устройстве. Configure these settings using the Windows Security app on an individual device. Затем экспортировать конфигурацию в качестве XML-файла, чтобы можно было развернуть на других устройствах. Then, export the configuration as an XML file so you can deploy to other devices. Используйте групповую политику для распространения XML-файла сразу на нескольких устройствах. Use Group Policy to distribute the XML file to multiple devices at once. Вы также можете настроить смягчение с помощью PowerShell. You can also configure the mitigations with PowerShell.

В этой статье перечислены все меры по смягчению последствий, доступные в защите от эксплойтов. This article lists each of the mitigations available in exploit protection. В нем указывается, можно ли применять смягчение по всей системе или к отдельным приложениям, и содержит краткое описание работы по смягчению последствий. It indicates whether the mitigation can be applied system-wide or to individual apps, and provides a brief description of how the mitigation works.

В нем также описывается, как включить или настроить меры по смягчению последствий с помощью поставщиков служб конфигурации Windows Security, PowerShell и управления мобильными устройствами (MDM). It also describes how to enable or configure the mitigations using Windows Security, PowerShell, and mobile device management (MDM) configuration service providers (CSPs). Это первый шаг в создании конфигурации, которую можно развернуть по всей сети. This is the first step in creating a configuration that you can deploy across your network. Следующий шаг включает создание, экспорт, импорт и развертывание конфигурации на нескольких устройствах. The next step involves generating, exporting, importing, and deploying the configuration to multiple devices.

Некоторые технологии по смягчению последствий для безопасности могут иметь проблемы с совместимостью с некоторыми приложениями. Some security mitigation technologies may have compatibility issues with some applications. Необходимо протестировать защиту от эксплуатации во всех сценариях целевого использования с помощью режима аудита перед развертыванием конфигурации в производственной среде или остальной части сети. You should test exploit protection in all target use scenarios by using audit mode before deploying the configuration across a production environment or the rest of your network.

Использование смягчения защиты Exploit protection mitigations

Все смягчающие меры можно настроить для отдельных приложений. All mitigations can be configured for individual apps. Некоторые меры по смягчению последствий также могут применяться на уровне операционной системы. Some mitigations can also be applied at the operating system level.

Вы можете установить каждое из этих значений по умолчанию. You can set each of the mitigations on, off, or to their default value. Некоторые меры по смягчению последствий имеют дополнительные параметры, указанные в описании в таблице. Some mitigations have additional options that are indicated in the description in the table.

Значения по умолчанию всегда заданы в скобках в параметре Use default для каждого смягчения. Default values are always specified in brackets at the Use default option for each mitigation. В следующем примере по умолчанию для предотвращения выполнения данных существует значение «On». In the following example, the default for Data Execution Prevention is «On».

Конфигурация Использования по умолчанию для каждого из параметров смягчения указывает на нашу рекомендацию по базовому уровню защиты для повседневного использования для домашних пользователей. The Use default configuration for each of the mitigation settings indicates our recommendation for a base level of protection for everyday usage for home users. Развертывания предприятий должны учитывать защиту, необходимую для их индивидуальных потребностей, и, возможно, потребуется изменить конфигурацию вдали от по умолчанию. Enterprise deployments should consider the protection required for their individual needs and may need to modify configuration away from the defaults.

Для связанных с PowerShell cmdlets для каждого смягчения см. в справочной таблице PowerShell в нижней части этой статьи. For the associated PowerShell cmdlets for each mitigation, see the PowerShell reference table at the bottom of this article.

Если вы добавите приложение в раздел Параметры программы и настроите там отдельные параметры смягчения, они будут соблюдаться выше конфигурации для тех же смягчений, указанных в разделе Параметры системы. If you add an app to the Program settings section and configure individual mitigation settings there, they will be honored above the configuration for the same mitigations specified in the System settings section. В следующей матрице и примерах показано, как работают по умолчанию: The following matrix and examples help to illustrate how defaults work:

Включено в параметрах программы Enabled in Program settings Включено в параметрах System Enabled in System settings Поведение Behavior
Windows smm security mitigations table что это Windows smm security mitigations table что это Как определено в параметрах программы As defined in Program settings
Windows smm security mitigations table что это Windows smm security mitigations table что это Как определено в параметрах программы As defined in Program settings
Windows smm security mitigations table что это Windows smm security mitigations table что это Как определено в параметрах System As defined in System settings
Windows smm security mitigations table что это Windows smm security mitigations table что это По умолчанию, как определено в параметре Использование по умолчанию Default as defined in Use default option

    Пример 1 Example 1

    Mikael настраивает предотвращение выполнения данных (DEP) в разделе Параметры системы для отключения по умолчанию. Mikael configures Data Execution Prevention (DEP) in the System settings section to be Off by default.

    Затем Микаэль добавляет приложение test.exe в раздел Параметры программы. Mikael then adds the app test.exe to the Program settings section. В параметрах этого приложения в статье Предотвращение выполнения данных (DEP) он включает параметр параметры системы Override и задает переключатель На. In the options for that app, under Data Execution Prevention (DEP), he enables the Override system settings option and sets the switch to On. В разделе Параметры программы не указаны другие приложения. There are no other apps listed in the Program settings section.

    В результате deP будет включен только для test.exe. The result will be that DEP only will be enabled for test.exe. Все другие приложения не будут применяться к DEP. All other apps will not have DEP applied.

    Пример 2 Example 2

    Josie настраивает предотвращение выполнения данных (DEP) в разделе Параметры системы, которые будут отключены по умолчанию. Josie configures Data Execution Prevention (DEP) in the System settings section to be Off by default.

    Затем Джози добавляет приложение test.exe в раздел Параметры программы. Josie then adds the app test.exe to the Program settings section. В параметрах для этого приложения в статье Предотвращение выполнения данных (DEP) она включает параметр параметры системы Override и задает переключатель На. In the options for that app, under Data Execution Prevention (DEP), she enables the Override system settings option and sets the switch to On.

    Джози также добавляет приложениеmiles.exe в раздел Параметры программы и настраивает службу управления потоком (CFG) в On. Josie also adds the app miles.exe to the Program settings section and configures Control flow guard (CFG) to On. Она не включает параметры системы Переопределения для DEP или любые другие меры по смягчению последствий для этого приложения. She doesn’t enable the Override system settings option for DEP or any other mitigations for that app.

    В результате deP будет включен для test.exe. The result will be that DEP will be enabled for test.exe. DEP не будет включен для любого другого приложения, включая miles.exe. DEP will not be enabled for any other app, including miles.exe. CFG будет включен для miles.exe. CFG will be enabled for miles.exe.

    Если вы нашли какие-либо проблемы в этой статье, вы можете сообщить об этом непосредственно партнеру Windows Server/Windows Client или использовать номера технической поддержки Майкрософт для вашей страны. If you have found any issues in this article, you can report it directly to a Windows Server/Windows Client partner or use the Microsoft technical support numbers for your country.

    Настройка системных смягчений с помощью приложения Безопасности Windows Configure system-level mitigations with the Windows Security app

    Откройте приложение Windows Security, выбрав значок щита в панели задач или нажав меню пусковых пусков для Defender. Open the Windows Security app by selecting the shield icon in the task bar or searching the start menu for Defender.

    Выберите плитку управления & браузера (или значок приложения в левой панели меню), а затем выберите защиту exploit. Select the App & browser control tile (or the app icon on the left menu bar) and then select Exploit protection.

    В разделе Параметры системы найдите смягчение, необходимое для настройки, и выберите один из следующих. Under the System settings section, find the mitigation you want to configure and select one of the following. Приложения, которые не настроены по отдельности в разделе Параметры программы, будут использовать параметры, настроенные здесь: Apps that aren’t configured individually in the Program settings section will use the settings configured here:

    При изменении некоторых параметров может появиться окно управления учетной записью пользователя. You may see a User Account Control window when changing some settings. Введите учетные данные администратора, чтобы применить этот параметр. Enter administrator credentials to apply the setting.

    Изменение некоторых параметров может потребовать перезапуска. Changing some settings may require a restart.

    Повторите это для всех системных смягчений, которые необходимо настроить. Repeat this for all the system-level mitigations you want to configure.

    Перейдите в раздел Параметры программы и выберите приложение, которое необходимо применить к: Go to the Program settings section and choose the app you want to apply mitigations to:

    После выбора приложения вы увидите список всех смягчающих последствий, которые можно применить. After selecting the app, you’ll see a list of all the mitigations that can be applied. Чтобы включить смягчение, выберите шажок, а затем измените ползунок на On. To enable the mitigation, select the check box and then change the slider to On. Выберите дополнительные параметры. Select any additional options. Выбор аудита будет применяться только в режиме аудита. Choosing Audit will apply the mitigation in audit mode only. Вы будете уведомлены о необходимости перезапустить процесс или приложение или перезапустить Windows. You will be notified if you need to restart the process or app, or if you need to restart Windows.

    Повторите эти действия для всех приложений и смягчения последствий, которые необходимо настроить. Repeat these steps for all the apps and mitigations you want to configure. Выберите Применить, когда вы закончили настройку конфигурации. Select Apply when you’re done setting up your configuration.

    Теперь вы можете экспортировать эти параметры в качестве XML-файла или продолжить настройку специальных приложений для смягчения последствий. You can now export these settings as an XML file or continue on to configure app-specific mitigations.

    Экспорт конфигурации в виде XML-файла позволяет скопировать конфигурацию с одного устройства на другие устройства. Exporting the configuration as an XML file allows you to copy the configuration from one device onto other devices.

    Справка PowerShell PowerShell reference

    Вы можете использовать приложение Windows Security для настройки защиты от эксплойтов, или можно использовать cmdlets PowerShell. You can use the Windows Security app to configure Exploit protection, or you can use PowerShell cmdlets.

    Любые изменения, развернутые на устройстве с помощью групповой политики, переопределяют локализованную конфигурацию. Any changes that are deployed to a device through Group Policy will override the local configuration. При настройке начальной конфигурации используйте устройство, на которое не будет применена конфигурация групповой политики, чтобы не переопределять изменения. When setting up an initial configuration, use a device that will not have a Group Policy configuration applied to ensure your changes aren’t overridden.

    Для параметров системного уровня указывается параметр по умолчанию для этого NOTSET смягчения. For system-level settings, NOTSET indicates the default setting for that mitigation has been applied.

    Для параметров уровня приложения указывается, что параметр системного уровня для смягчения будет NOTSET применен. For app-level settings, NOTSET indicates the system-level setting for the mitigation will be applied.

    Параметр по умолчанию для каждого смягчения на уровне системы можно увидеть в Windows Security. The default setting for each system-level mitigation can be seen in the Windows Security.

    Используйте Set для настройки каждого смягчения в следующем формате: Use Set to configure each mitigation in the following format:

    Например, чтобы включить смягчение меры по предотвращению выполнения данных (DEP) с помощью эмуляции thunk ATL и для исполняемого под названием testing.exe в папке C:AppsLOBtests, а также предотвратить создание детских процессов, необходимо использовать следующую команду: For example, to enable the Data Execution Prevention (DEP) mitigation with ATL thunk emulation and for an executable called testing.exe in the folder C:AppsLOBtests, and to prevent that executable from creating child processes, you’d use the following command:

    Разделите каждый вариант смягчения с запятой. Separate each mitigation option with commas.

    Если вы хотите применить DEP на уровне системы, вы используете следующую команду: If you wanted to apply DEP at the system level, you’d use the following command:

    Вы также можете настроить некоторые меры по смягчению последствий для режима аудита. You can also set some mitigations to audit mode. Вместо того, чтобы использовать для смягчения эту меру, используйте комлет режима Аудита, как указано в таблице смдлетов по смягчению последствий. Instead of using the PowerShell cmdlet for the mitigation, use the Audit mode cmdlet as specified in the mitigation cmdlets table below.

    Например, чтобы включить произвольный код Guard (ACG) в режиме аудита для используемой ранееtesting.exe, необходимо использовать следующую команду: For example, to enable Arbitrary Code Guard (ACG) in audit mode for the testing.exe used previously, you’d use the following command:

    Справочная таблица PowerShell PowerShell reference table

    В этой таблице перечислены cmdlets PowerShell (и связанный с ним режим аудита), которые можно использовать для настройки каждого смягчения. This table lists the PowerShell cmdlets (and associated audit mode cmdlet) that can be used to configure each mitigation.

    Устранение рисков Mitigation Область применения Applies to Командлеты PowerShell PowerShell cmdlets Комлет режима аудита Audit mode cmdlet
    Диспетчерская система потока (CFG) Control flow guard (CFG) Системный и app-level System and app-level CFG, StrictCFG, SuppressExports CFG, StrictCFG, SuppressExports Аудит не доступен Audit not available
    Предотвращение выполнения данных (DEP) Data Execution Prevention (DEP) Системный и app-level System and app-level DEP, EmulateAtlThunks DEP, EmulateAtlThunks Аудит не доступен Audit not available
    Force randomization for images (Mandatory ASLR) Force randomization for images (Mandatory ASLR) Системный и app-level System and app-level ForceRelocateImages ForceRelocateImages Аудит не доступен Audit not available
    Рандомизация распределений памяти (Снизу вверх ASLR) Randomize memory allocations (Bottom-Up ASLR) Системный и app-level System and app-level BottomUp, HighEntropy BottomUp, HighEntropy Аудит не доступен Audit not available
    Проверка цепочек исключений (SEHOP) Validate exception chains (SEHOP) Системный и app-level System and app-level SEHOP, SEHOPTelemetry SEHOP, SEHOPTelemetry Аудит не доступен Audit not available
    Проверка целостности кучи Validate heap integrity Системный и app-level System and app-level TerminateOnError TerminateOnError Аудит не доступен Audit not available
    Произвольный охранник кода (ACG) Arbitrary code guard (ACG) Только на уровне приложений App-level only DynamicCode DynamicCode AuditDynamicCode AuditDynamicCode
    Блокировка изображений с низкой целостностью Block low integrity images Только на уровне приложений App-level only BlockLowLabel BlockLowLabel AuditImageLoad AuditImageLoad
    Блокировка удаленных изображений Block remote images Только на уровне приложений App-level only BlockRemoteImages BlockRemoteImages Аудит не доступен Audit not available
    Блокировка ненарушимого шрифта Block untrusted fonts Только на уровне приложений App-level only ОтключениеNonSystemFonts DisableNonSystemFonts AuditFont, FontAuditOnly AuditFont, FontAuditOnly
    Охрана целостности кода Code integrity guard Только на уровне приложений App-level only BlockNonMicrosoftSigned, AllowStoreSigned BlockNonMicrosoftSigned, AllowStoreSigned AuditMicrosoftSigned, AuditStoreSigned AuditMicrosoftSigned, AuditStoreSigned
    Отключение точек расширения Disable extension points Только на уровне приложений App-level only ExtensionPoint ExtensionPoint Аудит не доступен Audit not available
    Отключение вызовов системы Win32k Disable Win32k system calls Только на уровне приложений App-level only DisableWin32kSystemCalls DisableWin32kSystemCalls AuditSystemCall AuditSystemCall
    Не разрешайте детские процессы Do not allow child processes Только на уровне приложений App-level only DisallowChildProcessCreation DisallowChildProcessCreation AuditChildProcess AuditChildProcess
    Фильтрация адресов экспорта (EAF) Export address filtering (EAF) Только на уровне приложений App-level only EnableExportAddressFilterPlus, EnableExportAddressFilter [ 1 ] EnableExportAddressFilterPlus, EnableExportAddressFilter [1] Аудит не доступен [ 2 ] Audit not available[2]
    Фильтрация адресов импорта (IAF) Import address filtering (IAF) Только на уровне приложений App-level only EnableImportAddressFilter EnableImportAddressFilter Аудит не доступен [ 2 ] Audit not available[2]
    Имитация выполнения (SimExec) Simulate execution (SimExec) Только на уровне приложений App-level only EnableRopSimExec EnableRopSimExec Аудит не доступен [ 2 ] Audit not available[2]
    Проверка вызова API (CallerCheck) Validate API invocation (CallerCheck) Только на уровне приложений App-level only EnableRopCallerCheck EnableRopCallerCheck Аудит не доступен [ 2 ] Audit not available[2]
    Проверка использования ручки Validate handle usage Только на уровне приложений App-level only StrictHandle StrictHandle Аудит не доступен Audit not available
    Проверка целостности зависимостей изображений Validate image dependency integrity Только на уровне приложений App-level only EnforceModuleDepencySigning EnforceModuleDepencySigning Аудит не доступен Audit not available
    Проверка целостности стека (StackPivot) Validate stack integrity (StackPivot) Только на уровне приложений App-level only EnableRopStackPivot EnableRopStackPivot Аудит не доступен [ 2 ] Audit not available[2]

    [ 1. ] Используйте следующий формат, чтобы включить модули EAF для dlls для процесса: [1]: Use the following format to enable EAF modules for dlls for a process:

    [ 2. ] Аудит для этого смягчения не доступен с помощью cmdlets PowerShell. [2]: Audit for this mitigation is not available via PowerShell cmdlets.

    Настройка уведомления Customize the notification

    Дополнительные сведения о настройке уведомления при запуске правила и блокировке приложения или файла см. в примере Windows Security. For more information about customizing the notification when a rule is triggered and blocks an app or file, see Windows Security.

    Источник

    Видео

    🚩 Antimalware Service Executable

    🚩 Antimalware Service Executable

    Windows Modules Installer Worker Грузит Диск — Как Отключить TiWorker.exe

    Windows Modules Installer Worker Грузит Диск - Как Отключить TiWorker.exe

    Что такое SMM? Просто о сложном

    Что такое SMM? Просто о сложном

    У Meblox есть возможность стейкинга и не только. Разобраться сможет каждый

    У Meblox есть возможность стейкинга и не только. Разобраться сможет каждый

    Кто такой СММ | Что входит в задачи SMM специалиста?

    Кто такой СММ | Что входит в задачи SMM специалиста?

    🔥Apple Security — Божественная защита ваших данных!😎

    🔥Apple Security - Божественная защита ваших данных!😎

    Это приложение заблокировано вашим системным администратором

    Это приложение заблокировано вашим системным администратором

    Прошивка UEFI — Защита SMM

    Прошивка UEFI - Защита SMM

    Трафик на сайте MCG. А вы уже в проекте. Почему иногда сайт подгружается с задержкой.

    Трафик на сайте MCG. А вы уже в проекте. Почему иногда сайт подгружается с задержкой.

    msmpeng.exe windows defender грузит процессор и память на 100{e6878265e58fdd05daca7112d2ff3d42f014a5c156056e0b126954d43c927eeb} как отключить?

    msmpeng.exe windows defender грузит процессор и память на 100{e6878265e58fdd05daca7112d2ff3d42f014a5c156056e0b126954d43c927eeb} как отключить?

    Understanding the Windows SMM Security Mitigation Table (WSMT)

    The Windows SMM Security Mitigation Table (WSMT) is an ACPI table defined by Microsoft that allows system firmware to confirm to the operating system that certain security best practices have been implemented in System Management Mode (SMM) software. The WSMT table definition is described in the Windows SMM Security Mitigations Table (WMST) specification.

    Background

    The WSMT was defined to better support Windows Virtualization-based Security features. Please refer to Virtualization-based Security (VBS) for more background on VBS. Because SMM operates without the operating system’s knowledge or control, SMM represents a significant attack surface that could be leveraged by malicious code to compromise or circumvent the OS protections enabled through VBS. Delivering a robust and secure VBS platform requires careful scrutiny and likely updates of SMM code by the OEM to eliminate common vulnerabilities that may be exploited. The WSMT contains flags which firmware can set to indicate to the operating system which of these specific security best practices have been implemented.

    Implications of the WSMT on Windows VBS Support

    The WSMT Protection Flags field indicates the presence of these specific SMM security mitigations in the systems firmware. Supported versions of the Windows operating system read the WSMT Protection Flags early during initialization, prior to hypervisor and VBS launch, and may elect to enable, disable, or de-feature certain security features based on the presence of these SMM Protections Flags.

    Implementation Notes

    Proper implementation of the security mitigations represented by the WSMT Protection Flags FIXED_COMM_BUFFERS and COMM_BUFFER_NESTED_PTR_PROTECTION will require the firmware vendor carefully evaluate and possibly re-design the System Management Interrupt (SMI) handlers. All SMI handlers must be restricted to only access (read or write) to allowable memory regions that contain MMIO and EFI-allocated memory. It is not sufficient to check that pointers in SMM do not reference memory entirely outside of SMM. Rather, all SMM pointers must be validated to be within these safe memory regions. This prevents SMM from being exploited in a «confused deputy» attack, which could then be leveraged to compromise Windows VBS features. The above-mentioned Protection Flags refer only to input validation and pointer checks and do NOT currently require enforcement via SMM page protections. For example, SMM should not read or write to memory that was described by the firmware as EfiConventionalMemory because it may contain secrets or cause software to behave unpredictably.

    Validating the WSMT Protections

    Because SMM is opaque to the operating system, it is not possible to produce a test which runs in Windows to verify that the protections prescribed in the WSMT specification are actually implemented in SMM. From the operating system, the only check that is possible is to look for the presence of the WSMT, and check the state of all defined Protection Flags.

    Therefore, it is the responsibility of the OEM to carefully scrutinize each system’s SMM code and ensure that firmware complies with the guidance outlined in the WSMT specification and this article. No Protection Flag should be set to «true» until the OEM has confirmed that the mitigations corresponding to each Protection Flag value have been properly implemented. Failing to adhere to this as a best practice will leave the platform vulnerable to compromise, and negate the effectiveness of multiple OS protections and Windows security features which rely on VBS to maintain robust security boundaries.

    Supported versions of Windows

    Support for the WSMT is included in the following versions of Windows:

    Источник

    Microsoft добавит новые меры безопасности UEFI в Windows 10

    В прошлых публикациях, посвященных улучшениям безопасности Windows 10 [1,2,3,4], я неоднократно хвалил Microsoft за эти полезные нововведения. Новые механизмы безопасности помогают более эффективно бороться с эксплойтами. Пока очевидно, что Microsoft все больше делает ставку на новые технологии защиты от эксплойтов, основанные на виртуализации Virtualization Based Security, при этом добавляя более современные метрики безопасности и вынося выполнение критических по безопасности операций в отдельные виртуальные машины с высоким уровнем привилегий.

    На сей раз речь пойдет о безопасности прошивок UEFI. Известный гуру внутреннего устройства Windows Alex Ionescu опубликовал у себя в твиттере скриншот дополнительных требований безопасности UEFI, которые должны поддерживаться прошивками начиная с Windows 10 1703. Как известно, эта версия Windows 10 и может получить название очередного существенного обновления Redstone 2.

    Не секрет, что сама прошивка, ее компоненты и драйверы в современных ПК являются почти мини-ОС, которая получает управление еще до передачи упropравления загрузчику Windows. Столь стремительное распространение UEFI подталкивает security-ресерчеров к детальному поиску уязвимостей в прошивках и их драйверах, а производителей BIOS/UEFI к пересмотру механизмов их защиты. Злоумышленнику достаточно воспользоваться уязвимостью только в одном компоненте прошивки, чтобы скомпрометировать такие продвинутые VBS- технологии защиты Windows 10 как Device Guard, Credential Guard, Windows Defender Application Guard.

    Одним из подобных эксплойтов, который способен компрометировать все указанные выше технологии защиты Windows 10, основанные на виртуализации (VBS) является ThinkPwn, о котором я писал здесь. ThinkPwn использует уязвимость в драйвере прошивки для того, чтобы исполнить свой код на самом привилегированном уровне — SMM.


    Рис. Абстрактные уровни привилегий исполнения кода. Высший относится к Intel ME, далее SMM и гипервизор. Компрометация UEFI-прошивки позволяет компрометировать гипервизор и основанные на нем механизмы защиты (Device Guard, Credential Guard, Windows Defender Application Guard).

    Очевидно, что Microsoft учла вышеприведенные причины и добавила новые требования безопасности к прошивкам UEFI. Первое требование относится к фактической реализации DEP для прошивки. Т. е. страницы памяти с данными прошивки будут помечаться как NX (non-executable), что позволит исключить исполнение кода из ненадлежащих регионов памяти.

    VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable.

    Вторая функция безопасности относится к защите от эксплуатации уязвимостей, связанных с системной таблицей ACPI и драйверов (сервисов) UEFI. Для этого используется новая системная структура данных под названием Windows SMM Security Mitigations Table (WSMT).

    The Windows SMM Security Mitigations Table (WSMT) specification contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.

    Отметим, что в обоих случаях Microsoft подчеркивает, тот факт, что введенные методы безопасности обезопасят VBS от компрометации через уязвимости в прошивке.

    Reduces the attack surface to VBS from system firmware

    Источник

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

    Часть вторая. SMM

    Немножечко ликбеза
    Аппаратное SMI

    Писать про него особенно нечего: подаем напряжение на ногу — имеем прерывание. Сейчас используется редко, т.к. почти на всех системах теперь имеются мультифункциональные GPIO, которые могут генерировать события, не прерывая работу ОС, плюс не нужна дополнительная логика для определения, кто же конкретно сгенерировал аппаратное SMI, ведь устройств много, а нога — одна.

    Системные SMI
    Программные SMI

    Программные SMI генерируются чаще всего либо прошивкой, либо драйверами, но ничего не мешает атакующему с правами администратора в ОС (точнее, необходимы права на исполнение инструкции out) тоже генерировать их.
    Программное SMI генерируется при записи в CPU IO-порт APM_CNT (чаще всего это порт 0xB2), в качестве параметра в регистре AL передается его номер. Таким образом, максимальное количество различных обработчиков программных SMI в системе — 256, но реально их от 0-5 на специализированных системах, подготовленных для работы с RTOS, до 15-20 на системах с кучей разного железа, которым надо управлять без вмешательства ОС.

    Как реализован SMM

    Для кода SMM-диспетчера и обработчиков SMI выделяется 1-3 области физической памяти, которую во всех «обычных» режимах исполнения чипсет помечает как область MMIO с несуществующим устройством, т.е. для всего остального мира эти области — сплошная череда 0xFF, которые невозможно перезаписать. Первая область, называемая обычно ASEG (т.е. «сегмент А»), предназначена для т.н. legacy SMM code, т.е. старых 16-битных обработчиков SMI, которых на современных системах уже нет. Имя сегменту досталось за то, что он находится по фиксированным физическим адресам 0xA0000 — 0xBFFFF. Вторая область с фиксированными адресами — HSEG (т.е. «высокий сегмент»), раньше находилась на 0xFEDA0000 — 0xFEDBFFFF, но на современных системах не используется, т.к. имеется гораздо более удобный сегмент с настраиваемыми адресом и размером — TSEG (т.е. «топовый сегмент»), в котором и находятся сейчас 99% кода, исполняемого в SMM, а в ASEG остается только небольшая заглушка для совместимости.
    При переходе в SMM процессор сохраняет практически весь контекст (т.е. содержимое практически всех регистров, какие именно не сохраняются — зависит от конкретной микроархитектуры), причем к сохраненному контексту у обработчиков SMI есть полный доступ, и потому он может общаться с системой через изменение сохраненных значений.
    Для ОС вызов SMM кода выглядит как волшебное изменение содержимого регистров и памяти, и хотя отследить длительность нахождения в SMM все же можно по косвенным признакам, а факт перехода в него — по непосредственным, при помощи чтения регистра MSR_SMI_COUNT до и после вызова инициации программного прерывания, но повлиять на длительность обработчика SMI ОС не может, поэтому SMM плохо совместим с hard-RTOS (стоит отметить, что вся архитектура x86 совместима с ними весьма через раз, но это другая история).
    При настройках по умолчанию работающий в SMM код имеет полный доступ ко всей физической памяти на чтение и запись, полный доступ ко всем подключенным устройствам, в общем — может практически все, и при этом независим от ОС и недоступен из нее даже на чтение, что сильно затрудняет его анализ и делает код обработчиков SMI весьма привлекательной целью для атаки. Более того, если атакуемой системе доступна из SMM запись на SPI-микросхему (а она доступна во всех случаях, кроме систем с включенной PFAT, которые не найти с огнем, систем с Read-only BIOS’ом, которые встречаются еще реже, и систем с защитой через PR-регистры), то успешная атака может закончиться записью своего кода в BIOS, с последующем воровством, убийством и непотребством с гусями. Именно поэтому защитить SMM от вставки туда вредоносного кода — жизненно необходимо.

    Атаки на SMM и защита от них
    Забытый D_LOCK

    Код в SMRAM не появляется там самостоятельно, сначала саму SMRAM нужно настроить, инициализировать физическую память, настроить TSEG так, чтобы все обработчики туда влезли, скопировать туда код SMM-диспетчера и обработчиков, настроить там таблицы дескрипторов — в общем, навести строгий уставной порядок, после чего обязательно снять бит D_OPEN, чтобы никто больше там ничего не испортил, и установить бит D_LOCK, чтобы D_OPEN нельзя было поставить назад. На некоторых старых системах установить D_LOCK забывали, и там SMM был отрыт всем ветрам, но во времена UEFI этого уже не происходит, так что этот вектор атаки ушел в историю.

    SMM cache poisoning

    Еще одна историческая атака — отравление кэша SMRAM, которую в 2009 году опубликовали Rafal Wojtczuk и Joanna Rutkowska. Суть атаки коротко — меняем тип памяти для региона SMRAM на Write-Back, организуем запись в регион SMRAM своего кода, запись в память не происходит, но при этом наш код остается в кэше второго уровня, после чего генерируем программное SMI и процессор читает данные не из SMRAM, а из кэша, и выполняет наш вредоносный код. Проблема решилась радикально — производители CPU запретили ставить режим WB на SMRAM, и потому системе с UEFI этой уязвимости не подвержены.

    SMM call-out, она же SMM incursion attack

    Please, please, please, go apply patches!

    DMA attack
    SMM cross-buffer attack

    Представленная специалистами из Intel ATR атака на обработчики SMI, которые принимают в качестве параметра указатель и размер буфера, и производят запись в него. Атакующий может передать указатель и размер таким образом, чтобы буфер пересекал границу RAM-SMRAM, а т.к. обработчик SMI имеет доступ к SMRAM, то он перепишет какую-то часть данных вначале SMRAM. При удачном стечении обстоятельств (т.е. приблизительно после 500 часов отладки минимум) обработчик может переписать служебные структуры диспетчера SMM или других обработчиков нужным атакующему образом, и он получит возможность выполнения произвольного SMM-кода. Атака адски сложная и целевая, но вполне возможная, поэтому с начала 2015 года все обработчики SMI, принимающие указатели на буфер, обязаны валидировать его перед использованием. На более старых системах атака будет работать, но вероятность того, что именно вас через нее взломают — невелика.

    Заключение

    Ну вот, теперь разобрались более или менее и с SMM, в следующей части поговорим об атаках на S3 BootScript.
    Спасибо за внимание, безопасных вам прошивок.

    Источник

    основные сведения о таблице защиты Windows SMM (WSMT)

    таблица по обеспечению безопасности Windows SMM (WSMT) — это таблица ACPI, определенная корпорацией майкрософт, которая позволяет системному встроенному по проверить операционную систему на наличие определенных рекомендаций по обеспечению безопасности в программном обеспечении (SMM). определение таблицы WSMT описано в спецификации Windows таблицы мер безопасности SMM (вмст).

    Историческая справка

    влияние использования WSMT на поддержку Windows VBS

    В поле Флаги защиты WSMT указываются сведения о наличии этих конкретных угроз безопасности SMM в встроенном программном обеспечении системы. поддерживаемые версии операционной системы Windows читать флаги защиты WSMT на ранних этапах инициализации, до запуска гипервизора и VBS, а также включать, отключать или отменять некоторые функции безопасности в зависимости от наличия этих флагов защиты SMM.

    Примечания по реализации

    Правильная реализация средств обеспечения безопасности, представленных флагами защиты WSMT FIXED_COMM_BUFFERS и COMM_BUFFER_NESTED_PTR_PROTECTION, требует тщательного анализа и, возможно, перепроектирования обработчиков прерываний управления системой (SMI). Все обработчики SMI должны быть ограничены доступом (для чтения или записи) к допустимым областям памяти, содержащим память MMIO и, выделенную EFI. Не вполне достаточно проверить, что указатели в SMM не ссылаются на память целиком за пределами SMM. Вместо этого все указатели SMM должны быть проверены в пределах этих областей памяти. это предотвращает использование SMM при атаке «путают deputy», которая затем может быть использована для взлома Windows VBS. Указанные выше флаги защиты относятся только к проверке входных данных и проверкам указателей, и в настоящее время не требует принудительного применения с помощью защиты страниц SMM. Например, SMM не следует считывать или записывать данные в память, которая была описана встроенным по как Ефиконвентионалмемори, поскольку она может содержать секреты или вызывать непредсказуемое поведение программного обеспечения.

    Проверка защиты в WSMT

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

    Таким образом, поставщик вычислительной техники должен тщательно сопротивляются код SMM каждой системы и убедиться, что встроенное по соответствует рекомендациям, изложенным в спецификации WSMT и этой статье. Флаг защиты не должен иметь значение «true» до тех пор, пока поставщик вычислительной техники не подтвердил, что для каждого значения флага защиты были правильно реализованы все меры по устранению. если не придерживаться этого способа, это позволит оставить платформу уязвимой для компрометации и отменять эффективность нескольких средств защиты ос и Windows функции безопасности, использующие VBS для поддержания надежных границ безопасности.

    Поддерживаемые версии Windows

    Поддержка WSMT включена в следующие версии Windows:

    Источник

    Microsoft добавит новые меры безопасности UEFI в Windows 10

    В прошлых публикациях, посвященных улучшениям безопасности Windows 10 [1,2,3,4], я неоднократно хвалил Microsoft за эти полезные нововведения. Новые механизмы безопасности помогают более эффективно бороться с эксплойтами. Пока очевидно, что Microsoft все больше делает ставку на новые технологии защиты от эксплойтов, основанные на виртуализации Virtualization Based Security, при этом добавляя более современные метрики безопасности и вынося выполнение критических по безопасности операций в отдельные виртуальные машины с высоким уровнем привилегий.

    На сей раз речь пойдет о безопасности прошивок UEFI. Известный гуру внутреннего устройства Windows Alex Ionescu опубликовал у себя в твиттере скриншот дополнительных требований безопасности UEFI, которые должны поддерживаться прошивками начиная с Windows 10 1703. Как известно, эта версия Windows 10 и может получить название очередного существенного обновления Redstone 2.

    Не секрет, что сама прошивка, ее компоненты и драйверы в современных ПК являются почти мини-ОС, которая получает управление еще до передачи упropравления загрузчику Windows. Столь стремительное распространение UEFI подталкивает security-ресерчеров к детальному поиску уязвимостей в прошивках и их драйверах, а производителей BIOS/UEFI к пересмотру механизмов их защиты. Злоумышленнику достаточно воспользоваться уязвимостью только в одном компоненте прошивки, чтобы скомпрометировать такие продвинутые VBS- технологии защиты Windows 10 как Device Guard, Credential Guard, Windows Defender Application Guard.

    Одним из подобных эксплойтов, который способен компрометировать все указанные выше технологии защиты Windows 10, основанные на виртуализации (VBS) является ThinkPwn, о котором я писал здесь. ThinkPwn использует уязвимость в драйвере прошивки для того, чтобы исполнить свой код на самом привилегированном уровне — SMM.


    Рис. Абстрактные уровни привилегий исполнения кода. Высший относится к Intel ME, далее SMM и гипервизор. Компрометация UEFI-прошивки позволяет компрометировать гипервизор и основанные на нем механизмы защиты (Device Guard, Credential Guard, Windows Defender Application Guard).

    Очевидно, что Microsoft учла вышеприведенные причины и добавила новые требования безопасности к прошивкам UEFI. Первое требование относится к фактической реализации DEP для прошивки. Т. е. страницы памяти с данными прошивки будут помечаться как NX (non-executable), что позволит исключить исполнение кода из ненадлежащих регионов памяти.

    VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable.

    Вторая функция безопасности относится к защите от эксплуатации уязвимостей, связанных с системной таблицей ACPI и драйверов (сервисов) UEFI. Для этого используется новая системная структура данных под названием Windows SMM Security Mitigations Table (WSMT).

    The Windows SMM Security Mitigations Table (WSMT) specification contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.

    Отметим, что в обоих случаях Microsoft подчеркивает, тот факт, что введенные методы безопасности обезопасят VBS от компрометации через уязвимости в прошивке.

    Reduces the attack surface to VBS from system firmware

    Источник

    As mentioned earlier this week, Microsoft just released a spec for their new ACPI table WSMT (Windows SMM Security Mitigations Table):

    Windows SMM Security Mitigations Table

    The Windows SMM Security Mitigations Table specification contains details of an ACPI table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features. This information applies for Windows Server Technical Preview 2016, and Windows 10, version 1607. […]

    Full spec:
    http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx

    The UEFI Forum maintains ACPI specs. AFAICT, their ACPI spec list does not yet list this new WSMT table.
    http://www.uefi.org/acpi

    Also, there’s a strange copyright in this spec:

    Portions of this software may be based on NCSA Mosaic. NCSA Mosaic was developed by the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. Distributed under a licensing agreement with Spyglass, Inc.

    Maybe I am just noticing this paragraph, and Microsoft always uses that on copyright pages, and does not mention other old software, only NCSA Mosaic. But why NCSA Mosaic-centric copyrights in an WSMT ACPI table?? Microsoft IE 1.0 was based on NCSA Mosaic source code, via Spyglass purchase, but that was long before EFI or ACPI. I didn’t notice anything Win9x/BIOS/ISA-PNP-centric about WSMT. :-).

    In related news, Jiewen Yao of Intel has submitted the WSMT definition into the tianocore EDK-II project:

    MdePkg: Add WSMT definition. This patch adds Windows SMM Security Mitigation Table @ http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx

     …/WindowsSmmSecurityMitigationTable.h            | 39 ++++++++++++++++++++++
     1 file changed, 39 insertions(+)

    +#define EFI_ACPI_WINDOWS_SMM_SECURITY_MITIGATION_TABLE_SIGNATURE  SIGNATURE_32(‘W’, ‘S’, ‘M’, ‘T’)

    Jiewen also submitted a 12-part patch, enhancing SMM to deal with this new table:

    [PATCH 00/12] Enhance SMM Communication by using fixed comm buffer. This series patches are generate to meet Microsoft WSMT table definition on FIXED_COMM_BUFFERS requirement. Before this series patches, the DXE or OS module can use any non-SMM memory as communication buffer to exchange data with SMM agent. Microsoft WSMT table has requirement to support fixed communication buffer – so that SMM agent can only support communication buffer with type EfiReservedMemoryType/EfiRuntimeServicesCode/EfiRuntimeServicesData/EfiACPIMemoryNVS, which will not be used by OS during runtime. So we clean up all SMM handler to only use these memory regions for SMM communication, and enhance check in SmmMemLib to catch the violation. This series patches are validated on real platforms with SMM enabled. This series patches are validated on OVMF ia32-x64 with SMM enabled.

    For full patch, see list archives:
    https://lists.01.org/mailman/listinfo/edk2-devel

    Оценка статьи (5 / 2)

    UEFI boot – это программа нового поколения, которая ускорит загрузку компьютера и она по структуре напоминает BIOS.

    BIOS – это предпрограмма (код, вшитый в материнскую плату компьютера). Он запускается до загрузки операционной системы, проверяя работоспособность компьютера и отладку оборудования (драйверов). UEFI, в отличие от привычного BIOS-a, представляет собой графический интерфейс, гибко запрограммированный и действительно позволяющий быстрее запустить ОС.

    Расположена предпрограмма поверх всей аппаратной начинки компьютера, а ее код, значительно превышающий BIOS по размерам, физически может находиться в любом месте – в микросхеме памяти на материнской плате, на жестком диске или в сетевом хранилище. Благодаря этому она напоминает операционную систему, только в упрощенном варианте. При запуске компьютера сперва загружается служба UEFI, проверяя все компоненты последнего , а затем непосредственно операционная система.

    Как отключить Secure Boot в BIOS ноутбука

    Доброго времени суток. Довольно часто многие пользователи задают вопросы насчет Secure Boot (например, данную опцию иногда требуется отключить при установке Windows). Если ее не отключить, то эта защитная функция (разработанная Microsoft в 2012г.) будет проверять и искать спец. ключи, которые имеются только у ОС Windows 8 (и выше). Соответственно, загрузить ноутбук с какого-либо носителя вы не сможете…
    В этой небольшой статье я хочу рассмотреть несколько популярных марок ноутбуков (Acer, Asus, Dell, HP) и показать на примере, как отключить Secure Boot.

    В ажная заметка! Чтобы отключить Secure Boot, необходимо зайти в BIOS — а для этого нужно нажать соответствующие кнопки сразу после включения ноутбука. Этому вопросу посвящена одна из моих статей — https://pcpro100.info/kak-voyti-v-bios-klavishi-vhoda/. В ней указаны кнопки для разных производителей и подробно рассказано, как войти в BIOS. Поэтому, в этой статье я на этом вопросе останавливаться не буду…

    (Скриншоты из BIOS ноутбука Aspire V3-111P)

    После того, как вошли в BIOS, необходимо открыть вкладку «BOOT» и посмотреть активна ли вкладка « Secure Boot «. Скорее всего, она будет не активной и ее нельзя будет изменить. Такое происходит из-за того, что не установлен пароль администратора в разделе BIOS « Security «.

    Чтобы его установить, следует открыть данный раздел и выбрать пункт « Set Supervisor Password » и нажать на Enter.

    Далее ввести и подтвердить пароль и нажать Enter.

    Собственно, после этого можно открыть раздел « Boot » — вкладка « Secure Boot » будет активна и ее можно переключить в Disabled (т.е. выключить, см. скриншот ниже).

    После проведенных настроек, не забудьте сохранить их — кнопка F10 позволит сохранить все произведенные изменения в BIOS и выйти из него.

    После перезагрузки ноутбука, он должен грузиться с любого* загрузочного устройства (например, с флешки с Windows 7).

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

    1. Сначала заходим в BIOS и открываем раздел « Security «. В самом низу будет пункт « Secure Boot Control » — его нужно переключить в disabled, т.е. выключить.

    Далее нажимайте кнопку F10 — настройки будут сохранены, а ноутбук отправиться перезагружаться.

    2. После перезагрузки снова войтдите в BIOS и затем в разделе «Boot» сделайте следующее:

    • Fast Boot — переводим в режим Disabled (т.е. отключаем быструю загрузку. Вкладка есть не везде! Если у вас ее нет — то просто пропустите эту рекомендацию);
    • Launch CSM — переключаем в режим Enabled (т.е. включаем поддержку и совместимость со «старыми» ОС и ПО);
    • Затем снова жмем F10 — сохраняем настройки и перезагружаем ноутбук.

    3. После перезагрузки входим в BIOS и открываем раздел « Boot » — в пункте « Boot Option» можно бужет выбрать загрузочный носитель, который подключен к USB порту (например). Скриншот ниже.

    Затем сохраняем настройки BIOS и перезагружаем ноутбук (кнопка F10).

    (Скриншоты с ноутбука Dell Inspiron 15 3000 Series)

    В ноутбуках Dell отключение Secure Boot, наверное, одно из самых простых — достаточно одного захода в Bios и ненужно никаких паролей администраторов и пр.

    После входа в BIOS — откройте раздел «Boot» и задайте следующие параметры:

    • Boot List Option — Legacy (этим мы включаем поддержку старых ОС, т.е. совместимость);
    • Security Boot — disabled (отключаем защищенную загрузку).

    Собственно, далее можно отредактировать очередь загрузки. Большинство устанавливает новую ОС Windows с загрузочных USB флешек — поэтому ниже привожу скриншот, какую строку нужно подвинуть на самый верх, чтобы можно было загрузиться с флешки (USB Storage Device).

    После введенных настроек нажмите кнопку F10 — этим вы сохраните введенные настройки, а затем кнопку Esc — благодаря ей вы выйдите из BIOS и перезагрузите ноутбук. Собственно, на этом отключение защищенной загрузки на ноутбуке Dell — завершено!

    После входа в BIOS, откройте раздел « System Configuration «, а затем перейдите во вкладку « Boot Option » (см. скриншот ниже).

    Далее переключите « Secure Boot » в Disabled, а « Legacy Support » в Enabled. Затем сохраните настройки и перезагрузите ноутбук.

    После перезагрузки появиться текст «A change to the operating system secure boot mode is pending…».

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

    После этого изменения ноутбук перезагрузиться, а Secure Boot будет отключен.

    Чтобы загрузиться с флешки или диска: при включении ноутбука HP нажмите на ESC, а в стартовом меню выберите пункт «F9 Boot Device Options», дальше сможете выбрать устройство, с которого хотите загрузиться.

    Для отключения можно использовать различные способы.

    Первый из которых возможен при наличии на вашем устройстве операционной системы Windows 8 или выше.

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

    Затем следует выбрать пункт «Восстановление» в разделе «Обновление и восстановление» и кликнуть по кнопке «Перезагрузить сейчас» с использованием особых вариантов загрузки компьютера.

    Выбираем параметры загрузки

    В дополнительных параметрах выбираете настройки UEFI и производите перезагрузку устройства.

    Пункт выбора UEFI

    Еще одним способом, позволяющим войти в БИОС вашего ноутбука, является использование комбинации клавиш Fn + F2 .

    После этого вы также получите доступ ко всем настройкам BIOS.

    На некоторых ОС «горячие клавиши» могут отличаться.

    Так у стационарных компьютеров это чаще всего клавиша Delete , а у большинства ноутбуков — F2 .

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

    Для начала стоит рассмотреть настройки БИОС InsideH20 setup utility с имеющейся функцией UEFI, так как это распространенный набор микропрограмм для большинства ноутбуков.

    Сюда можно отнести устройства таких брендов как Acer и Toshiba, перевод Secure Boot в неактивное состояние на которых несколько схоже.

    Установка Windows UEFI

    Установка windows через BIOS кардинально отличается от установки через UEFI. Первым делом необходимо создать загрузочную флешку. Одна из самых подходящих для таких целей программ – утилита Rufus 1.4.6. Она бесплатная, не требует установки и поэтому не занимает много места на жестком диске или съемном носителе. Что важно , она подходит для GPT-разметки жесткого диска и может работать со спецификацией UEFI. Подходящее обновление утилиты можно скачать на официальном веб-сайте разработчиков.

    Запускаем утилиту и указываем название флешки, предназначенной для установки(предварительно нужно удалить важные файлы, очистив память). В пункте «File system» (файловая система) выбираем FAT 32, далее в качестве схемы раздела – GPT (GUID Partition Table), системный интерфейс – UEFI. Поставьте галочку у пункта «Create a bootable disk using:» (создать загрузочное устройство с использованием…), выберите рядом ISO Image и укажите полный путь к ISO-образу операционной системы Windows.

    Установка Windows UEFI

    После введения всех описанных параметров можно нажимать на « Start » и программа самостоятельно подготовит флеш-накопитель к загрузке ОС. Время, затраченное на этот процесс, зависит от быстродействия вашего компьютера и от поколения USB.

    Если работа утилиты Rufus вас не устраивает или появляются проблемы с загрузкой UEFI, можно использовать абсолютно аналогичную программу, которая называется WinSetupFromUSB.

    Скачивание также доступно на сайте производителя, а ее название (в переводе «Загрузка Windows с USB») говорит само за себя. Загрузочная флешка создается полностью аналогично, так как программы имеют практически одинаковый интерфейс.

    Отключение на устройствах Acer

    Используя клавишу F2 в самом начале загрузки операционной системы откройте окно BIOS.

    Зайдя таким образом в настройки BIOS UEFI необходимо будет перейти в раздел «Main» и из присутствующего списка выбрать пункт «F12 Boot Menu».

    По умолчанию данная функция активна, однако, ее следует деактивировать, установив напротив нее параметр [Disabled] .

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

    После этого необходимо с помощью клавиш со стрелками переместиться в раздел «Security» и выбрать пункт «Set Supervisor Password».

    Отключение на ноутбуке Toshiba

    Необходимо найти раздел «Security», который присутствует в верхнем списке меню.

    Не забывайте, что все перемещения по списку производятся при помощи клавиш со стрелками.

    BIOS ноутбука Тошиба

    Выбрав таким образом необходимый пункт — жмете на клавишу Enter , чтобы войти в его настройки.

    После этого опускаетесь к опции «Secure Boot», расположенной в нижней части вкладки.

    По умолчанию данная функция включена и имеет надпись [Enabled] .

    При нажатии на данном пункте кнопкой Enter вам представится возможность выбрать вариант [Disabled] — отключено.

    С помощью этих действий вы отключите функцию Secure Boot на своем ноутбуке, но для того, чтобы установить на него другую операционную систему — этого будет недостаточно.

    На данной вкладке среди имеющегося списка найдите пункт «System Configuration» и нажмите кнопку Enter .

    Войдя в настройки данного пункта выберите строку «Boot Mode» (в некоторых моделях может быть «OS Mode Selection») и в открывшемся меню перейдите из установленного по умолчанию положения «UEFI Boot» (на некоторых устройствах может быть «UEFI OS») в режим «CSM Boot» (могут быть и такие варианты, как «CMS OS», «UEFI and Legacy OS»).

    После проведения всех настроек следует нажать клавишу F10 , чтобы они вступили в силу, а в открывшемся окне «Save & reset» подтвердить свое намерение выбором пункта «Yes» и нажать клавишу Enter .

    Завершающим этапом будет перезагрузка ноутбука, после которой вы сможете установить на устройство любую другую операционную систему.

    Для этого вам снова придется войти в БИОС, используя клавишу F10 либо Esc , и выбрать в его настройках подключенную установочную флешку или загрузочный компакт диск.

    Как узнать, включен ли режим безопасного запуска

    Этот вариант подходит для восьмой и десятой версий Windows. Нажмите кнопки Windows+R и в полученном окне введите команду «msinfo32» ( без кавычек). Нажмите кнопку Enter.

    В появившемся окне слева следует выбрать раздел «Сведения о системе», а справа найти строку «Состояние безопасной загрузки». Столбец «Значение» показывает , включена или отключена рассматриваемая функция.

    Как узнать, включен ли режим безопасного запуска

    Отключение на ноутбуке Samsung

    На устройствах данного производителя устанавливается программа Aptio Setup utility, ее открытие происходит в момент запуска нажатием клавиши F2 .

    Войдя таким образом в BIOS следует открыть настройки раздела «Boot».

    В нем необходимо выбрать пункт «Secure Boot» и перевести его из состояния [Enabled] (включено) в положение [Disabled] (отключено).

    Перемещение производится с помощью клавиш со стрелками, а подтверждение изменения — кнопкой Enter .

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

    Этот пункт следует перевести в положение «UEFI and Legacy OS» либо «CSM OS» и вновь нажать на клавиатуре Enter .

    Перед вами снова появится сообщение о возможном появлении ошибки в процессе перезагрузки.

    Игнорируйте его нажатие клавиши Enter , после чего перезагрузите ноутбук с сохранением новых настроек.

    Для этого необходимо нажать на клавишу F10 и согласиться с сохраняемыми изменениями, выбрав вариант «Yes».

    Когда ПК будет перезагружаться, нажмите F10 , перед вами откроется меню загрузки.

    В нем вам предстоит выбрать один из вариантов — жесткий диск компьютера, компакт-диск или флешку.

    Как создать установочную флешку для компьютера с UEFI

    С переходом на UEFI изменились и требования к загрузочным USB-флешкам. Теперь флешки, созданные по старым правилам, например, при помощи утилиты Microsoft Windows USB/DVD Download Tool, можно использовать лишь для установки устаревших и 32-битных версий ОС в режиме эмуляции BIOS.
    Чтобы поставить на комп Windows 10 x64 в режиме UEFI с активным Secure Boot, загрузочный носитель должен иметь файловую систему FAT32. Это накладывает ограничение на его объем (максимум 4 Гб), но NTFS, к сожалению, несовместим с протоколом безопасной загрузки. Зато в остальном процесс создания загрузочных флешек сильно упростился. Теперь это можно делать даже без программ.

    Самый простой способ создания установочной USB-флешки с Виндовс 10 – это обычное копирование на нее файлов дистрибутива. Таким же способом, как копируют данные из папки в папку. Создавать на флешке загрузчик не нужно, поскольку он уже входит в состав UEFI.

    Для копирования на флешку дистрибутива в формате ISO, последний достаточно открыть в проводнике Windows.

    Открытие файла iso в проводнике.

    Если у вас нет дистрибутива «десятки» или вы просто предпочитаете создавать загрузочные носители при помощи программ, используйте утилиту Microsoft . Чтобы подготовить флешку к установке, помимо нее самой и утилиты вам понадобится лишь доступ в Интернет. Как происходит «таинство» записи и каково в нем ваше участие, F1comp рассказывал в этой статье.

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

    Самое главное здесь – правильно выбрать схему раздела и тип системного интерфейса. Для совместимости с Secure Boot и дисками, вместительнее 2 Тб, выбирайте из списка «GPT для компьютеров с UEFI». Далее укажите программе путь к дистрибутиву и жмите кнопку Старт. Через 20-40 минут установочная флешка будет готова.

    Вариант отключения на устройствах Hewlett-Packard

    Выполнение данной операции на некоторых моделях ноутбуков HP может быть сопряжено с некоторыми дополнительными действиями.

    Одной из таких моделей является HP Pavilion.

    BIOS ноутбука HP

    Изначально следует запустить ноутбук и в самом начале загрузки (как только на экране монитора появятся самые первые символы) нажать и удерживать некоторое время кнопкой Esc .

    После этого появится «Startup Menu», которое содержит варианты загрузки.

    Далее нужно воспользоваться кнопкой F10 , чтобы попасть в окно настроек BIOS.

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

    Нажатием на Enter вы попадете в окно настроек данного пункта, в котором нужно выбрать из имеющегося списка пункт «Secure Boot».

    Чтобы его отключить — установите напротив него значение [Disabled] (отключено).

    После этого перейдите к пункту «Legacy support», отвечающему за совместимость с другими операционными системами.

    Переведите его в состояние [Enabled] , так как по умолчанию данная функция отключена.

    На ваши действия система выдаст предупреждение, которое необходимо проигнорировать и выбрать пункт «Yes».

    Далее жмете на кнопку Enter , после чего происходит стандартная перезагрузка.

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

    Для завершения произведенных настроек будет предложено ввести четырехзначный код и нажать на клавишу Enter .

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

    Создание загрузочной флешки UEFI вручную

    Ранее я писал, о том, Как сделать загрузочную флешку Windows 10 UEFI в Rufus, как сделать загрузочную флешку Windows 8 и 8.1 с поддержкой UEFI в программе Rufus. Вы можете использовать указанное руководство, если нет желания выполнять все действия в командной строке — в большинстве случаев, все проходит успешно, программа отличная.

    В этой инструкции загрузочная флешка UEFI будет создаваться с помощью командной строки — запустите ее от имени администратора (В Windows 7 найдите командную строку в стандартных программах, кликните правой кнопкой мыши и выберите запуск от имени администратора. В Windows 10, 8 и 8.1 нажмите клавиши Win + X на клавиатуре и выберите нужный пункт в меню).

    В командной строке по порядку введите следующие команды:

    • diskpart
    • list disk

    Выбор USB накопителя в Diskpart

    В списке дисков посмотрите, под каким номером находится подключенная к компьютеру флешка, на которую будет производиться запись, пусть это будет номер N. Введите следующие команды (все данные с USB накопителя будут удалены):

    • select disk N
    • clean
    • create partition primary
    • format fs=fat32 quick
    • active
    • assign
    • list volume
    • exit

    Подготовка загрузочной флешки UEFI

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

    Материнская плата ASUS

    Для удобства работы на некоторых моделях предусмотрено наличие русского языка, делающего интерфейс UEFI BIOS Utility понятным и доступным.

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

    Вид UEFI BIOS Utility

    Чтобы отключить функцию Secure Boot необходимо удерживать кнопку F2 или Delete в момент загрузки компьютера.

    Это позволит открыть окно «UEFI BIOS», находясь в котором следует нажать клавишу F7 .

    Открыв окно настроек вам понадобится перейти в пункт меню «Загрузка» и выбрать в нем параметр «Безопасная загрузка».

    В строке «Тип ОС» выбираете «Other OS» (другая ОС) вместо установленной по умолчанию «Windows UEFI mode».

    После этого необходимо вернуться в начальное окно раздела «Загрузка» и выбрать пункт CSM (Compatibility Support Module).

    Выделив данный пункт и нажав клавишу Enter , вы попадете в окно его настроек, в котором выбираете «Запуск CSM».

    Далее выбираете пункт «Параметры загрузочных устройств» и устанавливаете ему свойство «UEFI и Legacy OpROM» либо «Только Legacy OpROM».

    Перейдите в пункт «Загрузка с устройств хранения» и установите один из двух вариантов — «Both, Legacy OpROM first» либо «Сначала Legacy OpROM».

    Затем нажмите клавишу F10 , чтобы сохранить все произведенные изменения.

    Как отключить Secure boot в БИОСе

    Режим security в UEFI, или security boot, обеспечивает на ноутбуке, стационарном компьютере защиту при запуске: блокирует доступ к настройке изменения приоритета загрузки с CD/DVD, USB-накопителя (в том числе не даёт возможность пользоваться ОС с загрузочной флешки), предотвращает попытки установки нелицензированной, неавторизованной ОС, несанкционированного вмешательства в загрузочную оболочку. В таких ситуациях при загрузке на дисплее появляется надпись «secure boot violation», сигнализирующая о невозможности модификации загрузки в BIOS (в биосе), UEFI.

    Чтобы убрать эту блокировку, необходимо отключить в UEFI соответствующие опции. После отключения защиты можно изменять приоритет загрузки с дисков и USB-флешки, а также устанавливать любые дистрибутивы ОС.

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

    Проверка активности функции

    Статус активации защиты загрузки можно узнать двумя способами:

    Способ №1: в опциях

    1. Зажмите вместе на клавиатуре клавиши «Win» +«R».

    2. В панели «Выполнить» введите msinfo32, нажмите «Enter».

    3. Найдите параметр «Состояние … загрузки». Просмотрите его значение: «Откл.» — режим защиты выключен, «Вкл.» — включен.

    Способ №2: в консоли Powershell

    1. Запустите утилиту:

    • откройте меню «Пуск»;
    • в поисковой строке задайте название утилиты — powershell;

    2. Щёлкните в списке панели «Пуск» появившуюся строку с утилитой.

    Как открыть настройки UEFI/BIOS

    Чтобы деактивировать Security Boot, изначально нужно открыть загрузочную оболочку UEFI или BIOS. Выполнить эту процедуру также можно по-разному:

    Способ №1: при помощи «горячих клавиш»

    Перезапустите ОС. Нажимайте «Del». Если вход в оболочку не удалось выполнить, значит, используется другая «горячая клавиша» для входа в режим загрузочных настроек. Это может быть — «F2» или комбинация «FN+F2» (на ноутбуке).

    Примечание. Кнопка перехода в биос может указываться на мониторе в процессе запуска системы.

    Способ №2: штатная опция ОС

    (вариант для 8/8.1) 1. Активируйте выдвижную панель (в правой части экрана).

    2. Перейдите: Параметры → Изменение параметров … → Обновление и …→ Восстановление.

    3. В дополнительных надстройках выставьте режим перезапуска «Настройки по UEFI».

    4. Активируйте команду «Перезагрузить».

    Руководства по отключению

    Материнская плата ASUS (ПК)

    1. Перезапустите ПК. Нажмите клавишу «Del» или «F2» (зависит от конкретной модели ASUS). Когда на дисплее отобразится оболочка, нажмите «F7», отобразится «Advanced Mode».

    2. В «Boot» щёлкните по строке «Secure Boot».

    3. В панели настройки задайте «Other OS».

    4. Вернитесь в «Boot», Compatibility Support Module (CSM).

    5. Включите опцию Launch CSM: в её строке установите Enabled.

    6. В «Boot Device Control» задайте значение «UEFI and Legacy …» или « Legacy OpROM …».

    7. Ниже по списку, в «Boot … Devices», выберите «Both, Legacy … first» либо « Legacy OpROM …».

    Всё. Настройка завершена. Защита деактивирована. Нажмите «F10», подтвердите модификацию настроек. Перезагрузите ОС.

    Ноутбук Asus

    1. В загрузочной оболочке, в Security — Secure Boot, выставьте «Disabled».

    2. В «Boot» — Fast Boot смените параметр на «Disabled».

    3. Сохраните конфигурацию опций (F10), выполните перезагрузку. Откройте BIOS.

    4. В Boot — «Launch …» смените значение на «Enabled».

    5. Сохраните изменения и выполните перезагрузку ОС.

    Asrock

    1. В UEFI откройте «Security» (иконка «Щит» в верхнем меню).

    2. В «Secure Boot» переведите переключатель в «Disabled» (отключить).

    3. Нажмите «F10» для сохранения настроек. Выполните перезагрузку ПК.

    Gigabyte

    1. В UEFI откройте меню «… Features».

    2. Задайте опции:

    • Windows 8 Features — Other OS;
    • Boot Mode Selection» — «Legacy only» /«UEFI and Legacy» (возможные варианты);
    • Other PCI Device ROM Priority — Legacy OpROM.

    3. Сохраните выполненные модификации при помощи клавиши «F10».

    1. В меню оболочки перейдите: SETTINGS → Boot.

    2. В Boot Mode Select поменяйте параметр на «Legacy+UEFI».

    3. Нажмите F10 для сохранения изменений в опциях.

    Toshiba

    1. В Security- «Secure Boot» задайте положение «Disabled».

    2. Перейдите в оболочке: Advanced → System Configuration.

    3. Найдите «Boot Mode» (также он может называться OS Mode Selection) и установите его переключатель в положение «CSM Boot» (альтернативные названия параметра — CMS OS, UEFI and Legacy OS).

    4. Активируйте команду сохранения настроек клавишей «F10». Перезапустите систему. Теперь можно использовать загрузочные диски и флешки, а также устанавливать любые ОС.

    В ноутбуках HP Pavillion для деактивации нужно выполнить ещё несколько дополнительных настроек:

    1. Для входа в UEFI-BIOS в процессе перезагрузки нажимайте клавишу «F10» (в отдельных моделях: ESC → F10).

    2. В оболочке перейдите: System Configuration → Boot Options.

    3. Измените положение следующих опций:

    • Secure Boot — Disabled (отключение защитного режима);
    • Legacy support — Enabled (включение совместимости с другими ОС).

    4. В запросе с подтверждением изменений параметров выберите «Yes» (Да).

    5. Чтобы новые настройки вступили в силу, активируйте сохранение параметров клавишей F10.

    6. Перезагрузите ОС. По завершении перезапуска системы появится предупреждение и запрос на ввод указанного кода (отображается в строке … to complete the change). Наберите его и нажмите «Enter». Ноутбук автоматически перезагрузится.

    Для изменения приоритета загрузки в целях использования установочной USB-флешки в процессе включения ноутбука зайдите в стартовое меню (клавиша ESC) и выполните необходимые настройки в разделе «Boot Device Options» (клавиша F9).

    Samsung

    1. Чтобы перейти в оболочку UEFI-BIOS, в ходе запуска ноутбука нажимайте клавишу «F2».

    2. Перейдите в панель «Boot», установите курсор в строке «Secure Boot».

    3. В подменю измените его параметр на значение «Disabled».

    4. В сообщении с предупреждением выберите «OK» (подтвердите изменение).

    5. После отключения защиты в этом же перечне появится пункт «OS Mode Selection». Задайте в нём параметр CMS OS (или UEFI and Legacy OS).

    Acer Aspire

    1. В момент перезапуска ноутбука нажмите «F2».

    2. В панели Main, в опции «F12 Boot Menu», поставьте значение «Enabled».

    Примечание. Данная надстройка разрешает запрос загрузочного меню клавишей F12.

    3. В панели Security установите курсор в опции «Set Supervisor Password» и нажмите «Enter». В дополнительном поле введите два раза условный пароль.

    4. Когда появится сообщение «Changes… saved» снова нажмите «Enter».

    5. На вкладке Boot, в настройке Boot Mode, смените параметр на «Legacy».

    6. Сохраните изменения настроек (F10).

    7. Перезагрузите ноутбук и снова зайдите в UEFI-BIOS.

    8. Перейдите: Security → Set Supervisor Password. Нажмите «Enter», введите раннее установленный пароль. В последующих полях нажмите «Enter» без ввода данных.

    В сообщении «Changes… saved» снова используйте клавишу Enter. Теперь пароль сброшен и появился доступ к активации/деактивации защиты Secure Boot.

    Lenovo

    1. Зайдите в консоль UEFI при помощи клавиши F2 или комбинации Fn+F2 (в зависимости от модели).
    2. Откройте: раздел «Security» → опцию «Secure Boot». В её графе поставьте значение «Disabled».
    3. Сохраните значение опции (нажмите F10).

    В ноутбуках Dell, оснащённых оболочкой InsydeH2O, деактивация защиты выполняется так:

    1. В меню открывается: вкладка Boot → подраздел UEFI Boot.
    2. В строке «Secure Boot» устанавливается значение «Enabled».
    3. Сохраняются настройки, перезапускается ноутбук.

    Как видите, принцип отключения защиты Secure Boot на разных моделях практически одинаков за исключением лишь некоторых нюансов, связанных с местонахождением меню и дополнительными надстройками. Если даже в этом обзоре нет модели вашего ПК, ноутбука, используйте для деактивации защитной загрузочной опции базовый алгоритм. А именно: вход в оболочку UEFI → выключение Secure Boot (+ в некоторых компьютерах включение совместимости с другими ОС) → сохранение созданной конфигурации оболочки → перезагрузка системы.

    Успешной и быстрой вам настройки компьютера! Будьте предельно внимательны, изменяя значение опций в консоли UEFI.

    Старый-добрый BIOS

    Основные принципы функционирования BIOS (базовой системы ввода-вывода) для персональных компьютеров были определены еще в конце 70х годов прошлого века. На протяжении довольно большого промежутка времени, прошедшего с той поры, компьютерная отрасль интенсивно развивалась, это приводило к тому, что на определенных этапах возможностей BIOS было недостаточно, поскольку выпускаемые производителями устройства имели на борту новые технологии, часто не совместимые с текущими версиями BIOS. Что бы уйти от подобных проблем, разработчикам приходилось порой довольно существенно модифицировать код BIOS, однако целый ряд ограничений так и остался неизменным до настоящего времени. И, если первоначально архитектура BIOS была достаточно простой, то по прошествии времени она неминуемо усложнялась, адаптируясь под все новые и новые технологии, поэтому, к определенному моменту она стала напоминать нагромождение различного рода устаревшего и плохо взаимодействующего между собой кода. Ограничения, которые и по сей день можно встретить в коде BIOS, объясняются необходимостью сохранять совместимость с базовыми функциями, необходимыми для функционирования старого ПО. Всё это привело к тому, что BIOS, по сути, стал самым устаревшим компонентом современных ПК. На данный момент BIOS мало удовлетворяет требованиям новейшего оборудования и имеет следующие недостатки:

    1. 16-битный код, реальный режим. BIOS написан на языке ассемблера и функционирует на 16-битном коде в реальном режиме (real mode) процессора со свойственными ему ограничениями, самое существенное из которых — ограничение адресного пространства памяти объемом 1 Мегабайт.
    2. Отсутствие доступа к 64-битному железу. BIOS не способна напрямую взаимодействовать с 64-битным оборудованием, доминирующим на рынке в настоящее время.
    3. Отсутствие единого стандарта. Для BIOS отсутствует единая спецификация — каждый производитель предлагает собственный вариации реализации.
    4. Сложность разработки. Проблема заключается в том, что практически для каждой очередной модели системной платы производителем разрабатывается собственная версия BIOS, в которой реализуются уникальные технические особенности данного устройства: взаимодействие с модулями чипсета, периферийного оборудования и прч. Разработку BIOS можно разделить на два этапа. На первом этапе создается базовая версия микропрограммы, в которой реализуются те функции, которые не зависят от специфики оборудования. Разработчики подобного кода хорошо известны, это такие компании как American Megatrends (AMIBIOS), Phoenix Technologies (+ приобретенная ею легендарная Award Software (AwardBIOS)) и некоторые другие. На втором этапе к разработке BIOS подключаются программисты производителя материнской платы. Тут уже базовая сборка модифицируется под специфику каждой конкретной модели платы, учитываются ее особенности. После выхода системной платы на рынок, работа над прошивкой продолжается, регулярно выпускаются обновления, в которых исправляются ошибки, добавляется поддержка нового оборудования (например, процессоров) и, иногда даже расширяются функциональные возможности прошивки.

    Все эти, а так же некоторые другие, недостатки традиционной модели BIOS и привели к тому, что коалиция производителей аппаратуры и ПО начала работать над созданием спецификации UEFI. Начиная, по собственным наблюдениям, где-то с 2010 года, спецификация UEFI начала массово внедряться во все вновь выпускаемые материнские платы ведущих производителей, поэтому на данный момент найти новый компьютер с традиционным BIOS практически невозможно. Однако, сильно огорчаться из-за этого не стоит, поскольку многие производители в своих системных платах сохраняют совместимость с функционалом традиционных BIOS. К примеру, очень важным моментом является поддержка традиционного режима загрузки при помощи MBR. С этой целью был разработан UEFI-модуль режима эмуляции BIOS, который носит название Compatibility Support Module (CSM). Правда, я так полагаю, со временем все меньше и меньше производителей будут поддерживать в своих прошивках данный режим.

    Как отключить UEFI/Secure Boot (разблокировать BIOS)?

    Купил ноутбук Asus, хотел загрузится с загрузочного диска чтоб переустановить Windows 8, на Windows 7, не могу загрузится с диска, Что делать?

    Вам необходимо отключить так называемый режим — Secure Boot

    Просто находим изображение со своим BIOS и смотрим как в нем отключается UEFI.

    Secure Boot — это защитная функция, созданная в 2012 году корпорацией Майкрософт в результате чего не может быть доставлен в приоритете загрузки BIOS на CD / DVD диске, который означает, что вы не можете загрузить диск, и вы не можете поставить приоритет загрузки к USB, будь то флэш-накопитель USB или внешний жесткий внешний диск. Доступ Т.е. полностью закрыт, но вы можете отключить эту защиту, предусмотрен.

    В зависимости от способа, чтобы отключить производителей могут отличаться от описанных здесь, но в целом, суть остается той же. Главное понять, что цель Secure Boot — официальные ключи, которые пользователь должен приобрести за счет собственных средств.Вот 3 самых распространённых BIOS (и инструкция как отключить UEFI):

    В старых версиях BIOS-а отключить Secure Boot было довольно легко:

    В новых версиях BIOS-а, Secure Boot отключается на порядок сложнее. Просто находим Свое изображение (или изображениЯ) и смотрим на них как отключается этот самый Secure Boot.

    Алгоритм работы UEFI

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

    • Фаза SEC. (Security, Безопасность). Фаза безопасности. Все должно быть подписано и проверено иначе не будет запущено! Очистка CPU кэша.
    • Запуск главной процедуры инициализации в ROM.
    • Переход в защищенный режим работы процессора.
    • Инициализируются MTRR (диапазонные регистры типа памяти) для BSP.
    • Запуск патчей микрокода для всех установленных процессоров.
    • Начальная работа с BSP/AP. BSP = Board Support Package. AP = Application Processor. Каждое ядро может быть представлено как BSP + AP. Всем AP рассылается IIPI (Init Inter-processor Interrupt), затем SIPI (Start-up Inter-processor Interrupt).
    • Передача данных и управления в фазу PEI.
  • Фаза PEI. (Pre-EFI Initialization, Пред-EFI Инициализация). Подготовка платформы (памяти и обнаруженных устройств) для главной процедуры инициализации системы в фазе DXE.
      Перенос данных из ROM в кеш.
  • Инициализация CRTM (Core Root for Trust of Measurement). Это набор инструкций, который запускается платформой в ходе выполнения RTM-операций.
  • Загружается диспетчер PEI. Диспетчер загружает серию модулей (PEIM), которые варьируются в зависимости от платформы. Эти модули завершают оставшиеся задачи PEI. Стадия завершается, когда все модули загружены.
  • PEIM: Загружаются и запускаются модули инициализации процессоров. (пример: модуль кеша процессора, модуль выбора частоты процессора). Инициализируются процессоры.
  • PEIM: Встроенные интерфейсы платформы инициализируются (SMBus). Инициализируются MCH (Memory Controller Hub), ICH (I/O Controller Hub).
  • PEIM: инициализация памяти. Инициализация основной памяти и перенос в нее данных из кэша.
  • Проверка режима S3. Нет — передача управления в фазу DXE. Да — восстановление исходного состояния процессора и всех устройств и переход к ОС.
  • Фаза DXE. (Driver eXecution Environment, Среда загрузки драйверов). Загрузка компонентов этой фазы базируется на ресурсах, которые были инициализированы в фазе PEI. Фаза окончательной инициализации всех устройств. Запуск служб UEFI: Boot Services, Runtime Services и DXE Services.
      Загружается ядро DXE. Создается инфраструктура DXE: создаются необходимые структуры данных, база данных хендлов. Включает основные интерфейсы DXE. Запускает ряд сервисов: сервисы этапа загрузки (Boot Services), сервисы этапа выпонения (Runtime Services), сервисы фазы DXE (DXE Services).
  • Запуск диспетчера DXE. Посредством переданного из PEI списка Hand-off Block структур (HOB list) определяет доступные Firmware Volume (FV, структурированная база данных исполняемых модулей DXE: драйверов и приложений) и ищет в них драйвера, запускает их, соблюдая зависимости. В этот момент производится активация остальных компонентов, причем одновременно нескольких. Диспетчер грузит все доступные драйвера со всех доступных носителей.
  • Загрузка драйвера SMM Init. Инициирует подфазу. SMM (System management mode) — один из привилегированных режимов исполнения кода x86-процессора, в котором процессор переключается на независимое адресное пространство, сохраняет контекст текущей задачи, затем выполняет необходимый код, затем возвращается в основной режим. Зачем нам SMM? А потому что в этом режиме можно сделать с системой все что угодно и не зависимо от ОС. Код SMM может исполняться и после окончания фазы DXE.
  • Запускается UEFI Boot Manager. Это происходит после запуска всех драйверов. Управление передается в фазу BDS.
  • Фаза BDS. (Boot Device Selection, Выбор устройства загрузки). Реализует политику загрузки платформы. Основная задача — подключить устройства, необходимые для загрузки, выбрать (вручную или автоматически) устройство загрузки и загрузиться с него. Зачастую выполняет рекурсивный поиск по всем доступным FV и пытается найти доступный для загрузки контент.
      Инициализируются консольные устройства, описываемые переменными окружения ConOut (ConsoleOutHandle), ConIn (ConsoleInHandle), StdErr (StandardErrorHandle).
  • Загружаются UEFI-драйвера устройств, перечисленные в переменной окружения DriverOrder (содержащей опций Driver#### в порядке загрузки).
  • Загружается UEFI-приложение с устройства загрузки Boot####. Списки устройств содержатся в глобальной переменной окружения BootOrder в порядке очередности загрузки.
  • Если не смогли выполнить что-либо из вышеперечисленного, то вызываем диспетчер DXE для проверки обеспечения зависимостей дополнительных драйверов с момента последнего вызова диспетчера. После чего управление опять возвращается в фазу BDS.
  • Как отключить защиту Secure Boot в биосе

    Многие покупатели ноутбука или ПК, где есть предустановленная ОС Windows 8 хотят перезагрузиться с диска и переустановить на Windows 7, но при этом не получается решить проблему отключения Secure Boot в Windows 8.1. Для этих целей необходимо войти в конфигурацию BIOS и посмотреть, как будет происходить отключение режима UEFI. Вся информация об этом ниже.

    Непосредственное значение Secure Boot это защитная функция, которая разработана Майкрософт, где имеется доставленное для ПК в приоритете загрузка BIOS на CD / DVD диске. Это опция означает, что вы не можете осуществить загрузку диска, не можете осуществить приоритетную загрузку к USB и неважно, что в качестве этого будет использовано — диск или флэш-накопитель. Таким образом, доступ будет закрыт по умолчанию, но вы можете решить задачу как отключить Secure Boot в BIOS, используя простые подсказки. Нужно помнить одну вещь, что главной целью Secure Boot являются ключи, которые пользователь должен в обязательном порядке купить.

    Советы и рекомендации

    Главной особенности утилиты является проверка соответствия ключей и имеющихся подписей для загрузочной системы ПК, в том числе для Acer. Эта утилита предназначена для того, чтобы не было несанкционированного доступа в вашу операционную систему. Таким образом, чтобы избежать сложных действий по отключению утилиты, пользователь сначала должен отключить утилиту в UEFI.

    Интерфейс этой утилиты принадлежит не Майкрософту, как думают многие пользователи, а компании UEFI, которая является разработчиком БИОС для компьютеров и ноутбуков. Основная функция этой утилиты — полный запрет установки другой ОС, а также управление ключами, которые предусмотрены конфигурацией для любого ПК или ноутбука. Среди всех вариантов отключения заострим внимание на том, что UEFI Secure Boot отключить не получится только на планшете, где имеется предустановленная операционная система Windows.

    Если ваша операционная система «восьмёрка» или «десятка», тогда попробуем отключить утилиту в двух режимах.

    • Используем режим Setup. Эта функция необходима для того, чтобы можно было отключить и произвести замену основных ключей общего вида Platform Key, и KEK, а также обкатать на базе действия разрешённых и отозванных ключей типового исполнения DB и DBX.
    • Применяем в работе режим User или режим непосредственного пользователя, в котором работает юзер ПК.

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

    Преимущества и недостатки

    Позитив:

    • Высокий уровень безопасности – гарантирует защиту от функционирования руткитов в системных файлах операционной системы, работа которых приведёт к недействительности цифровых подписей модифицированных файлов.
    • Путём внесения в базу запрещенных для запуска операционных систем можно ограничить список загружаемых ОС.

    Негатив:

    • Все драйверы, которые запускаются на этапе загрузки ОС, должны быть подписанными, иначе они не загрузятся и соответствующие устройства не будут использоваться. Это требует согласования разработчиками системного программного обеспечения и производителями платформ момента добавления их ключей продуктов в доверенное хранилище.
    • Разработчики ОС не обязаны реализовывать функцию деактивации Secure Boot. Добавление ключей программами в доверенное хранилище должно быть запрещено, что усложняет эту процедуру и для пользователей.
    • Многие версии прошивок имеют уязвимости, позволяющие обходить Secure B

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

    Понравилась статья? Поделить с друзьями:
  • Windows smartscreen не дает установить программу
  • Windows smartscreen как отключить windows server
  • Windows smartscreen cant be reached right now что значит
  • Windows smartscreen cant be reached right now перевод
  • Windows smartscreen can t be reached right now что это