Geekly Articles each Day
📜 ⬆️ ⬇️

Schrödinger's trusted download. Intel Boot Guard


We suggest that you go down to a low level again and talk about the security of x86-compatible computer platform firmware. This time the main ingredient of the research is Intel Boot Guard (not to be confused with Intel BIOS Guard!), A hardware-supported BIOS trusted boot technology that a computer system vendor can permanently turn on or off during the production phase. Well, the research recipe is already familiar to us: thinly reverse-implement the implementation of this technology, describe its architecture, fill it with undocumented details, season to taste with attack vectors and mix. Let's add some fire to the story of how for years a cloned error in the production of several vendors allows a potential attacker to use this technology to create a hidden rootkit in the system that is not deleted (even by the programmer).

By the way, the article is based on the reports “Guarding rootkits: Intel BootGuard” from the 2016 ZeroNights conference and the 29th meeting of DefCon Russia (both presentations are here ).

Firmware for Intel 64 computer platform


First, let's answer the question: what is the firmware of a modern computer platform with Intel 64 architecture? Of course, UEFI BIOS. But this answer will not be accurate. Let's look at the drawing, which shows the desktop (laptop) version of this architecture.


The basis is a bunch:
')

Laptops, in addition to the above, assume the presence of a built-in controller (ACPI EC, Advanced Control and Power Interface Embedded Controller), which is responsible for the performance of the power subsystem, touchpad, keyboard, Fn-keys (screen brightness, sound volume, keyboard backlight, etc.). ) and other things. And he also has his own firmware.

So, the combination of the above firmware is the firmware of the computer platform (system firmware), which is stored on a shared SPI flash memory. So that the users of this memory are not confused, where is whose, the contents of this memory is divided into the following regions (as shown in the figure):



Access control to regions (in accordance with the specified permissions) is handled by the SPI master bus - an SPI controller built into the chipset through which the memory is accessed. If permissions are set to recommended (for security reasons) by Intel values, then each user of the SPI flash memory has full access (read / write) only to its region. And the rest are either read-only or inaccessible. A well-known fact: on many systems, the CPU has full access to the UEFI BIOS and GbE, read access only to flash descriptors, and access to the Intel ME region is not at all. Why many, but not all? What is recommended is optional. More details will be discussed later in the article.

Mechanisms for protecting the firmware of a computer platform from modification


Obviously, the firmware of a computer platform should be protected from a possible compromise that would allow a potential attacker to gain a foothold in it (relive the OS updates / reinstallations), execute its code in the most privileged modes, etc. And the separation of access to the regions of the SPI flash memory, of course, is not enough. Therefore, to protect the firmware from modifications, various mechanisms are applied, specific to each environment.

So, Intel ME firmware is signed to monitor integrity and authenticity, and is checked by the ME controller each time it is loaded into ME UMA memory. This verification process has already been reviewed by us in one of the articles on the Intel ME subsystem.

And the ACPI EC firmware is usually checked for integrity only. However, due to the fact that this binary is included in the UEFI BIOS, it almost always applies the same protection mechanisms that UEFI BIOS uses. We will talk about them.

These mechanisms can be divided into two categories.

Write protection in the UEFI BIOS region


  1. Physical protection of the contents of the SPI flash memory write-protect jumper;
  2. Protecting the projection of the UEFI BIOS region in the address space of the CPU using the PRx chipset registers;
  3. Block attempts to write to the UEFI BIOS region by generating and processing the corresponding SMI interrupt by setting the BIOS_WE / BLE and SMM_BWP bits in the chipset's registers;
  4. A more advanced option for such protection is Intel BIOS Guard (PFAT).

In addition to these mechanisms, vendors can develop and apply their own security measures (for example, signing capsules with UEFI BIOS updates).

It is important to note that on a particular system (depending on the vendor), not all of the above protection mechanisms can be applied, they can not be applied at all, but they can be vulnerable implemented. More information about these mechanisms and the situation with their implementation can be found in this article . For those interested, we recommend that you familiarize yourself with the entire cycle of articles on security of the UEFI BIOS from CodeRush .

UEFI BIOS authentication verification


When we talk about trusted boot technologies, the first thing that comes to mind is the Secure Boot. However, architecturally it is designed to authenticate external components with respect to the UEFI BIOS (drivers, bootloaders, etc.), and not the firmware itself.

Therefore, Intel in SoC-a with Bay Trail microarchitecture (2012) has implemented a hardware non-switchable Secure Boot (Verified Boot), which has nothing to do with the aforementioned Secure Boot technology. Later (2013), this mechanism was improved and released under the name Intel Boot Guard for desktops with the Haswell microarchitecture.

Before describing Intel Boot Guard, let us examine the runtime environments in the Intel 64 architecture, which, in combination, are the roots of trust for this trusted boot technology.

Intel CPU


Cap suggests that the processor is the main runtime environment in the Intel 64 architecture. Why is it the root of trust? It turns out that this is what makes it possession of the following elements:


Intel ME


As many as two articles were devoted to this subsystem in our blog. Recall that this executable environment is based on the microcontroller built into the chipset and is the most hidden and privileged in the system.

Despite secrecy, Intel ME is also a root of trust because it has:


Intel Boot Guard 1.x


A small disclaimer. The version numbers of the Intel Boot Guard technology that we use in this article are conditional and may have nothing to do with the numbering that is used in Intel's internal documentation. In addition, information provided here about the implementation of this technology was obtained during reverse engineering, and may contain inaccuracies compared with the specification for Intel Boot Guard, which is unlikely to ever be published.

So, Intel Boot Guard (BG) is a hardware-supported verification technology authenticity UEFI BIOS. Judging by its short description in [Platform Embedded Security Technology Revealed, head of Boot with Integrity, or Not Boot], it works like a chain of trusted downloads. And the first link in it is the boot code (microcode) inside the CPU, which is triggered by the RESET event (not to be confused with the RESET vector in the BIOS!). The CPU finds the code module (Intel BG startup ACM) developed and signed by Intel on the SPI flash memory, loads it into its cache, verifies (it was noted above that the CPU has a public key hash that verifies the ACM signature) and runs.



This code module is responsible for verifying the small starting part of the UEFI BIOS - Initial Boot Block (IBB), which, in turn, contains the functionality for verifying the main part of the UEFI BIOS. Thus, Intel BG allows you to verify the authenticity of the BIOS before loading the OS (which can be performed under the supervision of the Secure Boot technology).

Intel BG technology provides two modes of operation (and one does not interfere with the other, that is, both modes can be enabled on the system, and both can be turned off).

Measured boot


In the Measured Boot (MB) mode, each boot component (starting with the CPU boot ROM) “measures” the next, using the capabilities of the TPM (Trusted Platform Module). For those who do not know, we will explain.

TPM has PCRs (Platform Configuration Registers) that record the result of a hash operation using the formula:

Measure(data):PCR=Hash(PCR|Hash(data))



Those. the current PCR value depends on the previous one, while these registers are reset only during the system RESET.

Thus, in the MB mode at some point in time, the PCRs reflect a unique (within the scope of the hashing operation) identifier of the code or data that was “measured”. PCR values ​​can be used in some data encryption operations (TPM_Seal). After that, their decryption (TPM_Unseal) will be possible only if the PCR values ​​did not change as a result of the download (i.e., no “measured” component was modified).

Verified Boot


The most terrible thing for those who want to modify the UEFI BIOS is the Verified Boot (VB) mode, in which each boot component cryptographically checks the integrity and authenticity of the next. And in case of a verification error, one of the following occurs:


The choice of action depends on the specified Intel BG configuration (namely, the so-called enforcement policy), which is permanently recorded by the vendor of a computer platform in a specially designed storage - chipset fusions (FPFs). More on this point will stop later.

In addition to the configuration, the vendor generates two RSA 2048 keys and creates two data structures (shown in the figure):

  1. The vendor root key manifest (KEYM, OEM Root Key Manifest), which puts the SVN (Security Version Number) of this manifest, the SHA256 hash of the next manifest's public key, the RSA public key (that is, the public part of the vendor's root key) to verify the signature of this manifest and signature itself;
  2. IBB Manifesto (IBBM, Initial Boot Block Manifest), which puts the SVN of this manifest, the SHA256 IBB hash, the public key to verify the signature of this manifest and the signature itself.

The SHA256 public key hash of the OEM Root Key is permanently written to the chipset fyuz (FPFs), as is the Intel BG configuration. If the Intel BG configuration provides for the inclusion of this technology, then from this point on this system, update the BIOS (ie, be able to recalculate these manifests) can only the owner of the private part of the OEM Root Key, vendor



When looking at the picture, doubts immediately arise about the need for such a long chain of verification — one manifesto could be used. Why complicate things?

In fact, Intel thus provides the vendor with the opportunity to use different IBB keys for different product lines and one as the root. If the private part of the IBB key (with which the second manifest is signed) is lost, the incident will affect only one product line and only until the vendor generates a new pair and includes the recalculated manifests in the next BIOS update.

But if the root key (with which the first manifesto is signed) is compromised, it will not be possible to replace it, the revocation procedure is not provided because The hash of the public part of this key is programmed into FPFs once and for all.

Intel Boot Guard Configuration


Now let's dwell on the Intel BG configuration and the process of its creation. If you look at the corresponding tab in the GUI of the Flash Image Tool utility from the Intel System Tool Kit (STK), you will notice that the Intel BG configuration includes the hash of the public part of the vendor's root key, a couple of obscure values, and so on. Intel BG profile.



The structure of this profile is:

typedef struct BG_PROFILE { unsigned long Force_Boot_Guard_ACM : 1; unsigned long Verified_Boot : 1; unsigned long Measured_Boot : 1; unsigned long Protect_BIOS_Environment : 1; unsigned long Enforcement_Policy : 2; // 00b – do nothing // 01b – shutdown with timeout // 11b – immediate shutdown unsigned long : 26; };

In general, the Intel BG configuration is very flexible. Consider, for example, the flag Force_Boot_Guard_ACM. When it is removed, in case the BG startup ACM module on the SPI flash memory is not found, there will be no trusted boot. It will be untrusted.

We have already mentioned above that the enforcement policy for the VB mode can be configured in such a way that, in the event of a verification error, an untrusted download will occur again.

Leave such things to the discretion of vendors ...

GUI utilities provide the following "ready" profiles:
roomModeDescription
0No_FVMEIntel BG technology turned off
oneVEVB mode is turned on, shutdown by timeout
2VMEboth modes are enabled (VB and MB), shutdown by timeout
3VMboth modes are on, without shutting down the system
fourFveVB mode on, off immediately
fiveFvmeboth modes are on, immediate shutdown

As already mentioned, the Intel BG configuration must be recorded once and for all by the system vendor in chipset fyuz (FPFs) - a small (according to unchecked information, only 256 bytes) hardware storage of information inside the chipset that can be programmed outside of Intel’s production capacity (therefore, it is Field Programmable Fuses).

It is great for storing configurations because:


So, in order to set the configuration for Intel BG technology on a specific system, the vendor does the following during production:

  1. Using the Flash Image Tool utility (from Intel STK) it creates a firmware image with a given Intel BG configuration in the form of variables within the Intel ME region (the so-called temporary mirror for FPFs);
  2. Using the Flash Programming Tool (from Intel STK), this image is written to the SPI flash memory of the system and closes the so-called. manufacturing mode (in this case, the corresponding command is sent to Intel ME).

As a result of these operations, Intel ME commits to FPFs setpoints from a mirror for FPFs in the ME region, sets SPI flash descriptor resolutions to Intel recommended values ​​(described at the beginning of the article), and performs RESET systems.

Intel Boot Guard Implementation Analysis


In order to analyze the implementation of this technology with a specific example, we checked the following systems for signs of Intel BG technology:
SystemNote
Gigabyte GA-H170-D3HSkylake, there is support
Gigabyte GA-Q170-D3HSkylake, there is support
Gigabyte GA-B150-HD3Skylake, there is support
MSI H170A Gaming ProSkylake, no support
Lenovo ThinkPad 460Skylake, there is support, technology is included
Lenovo Yoga 2 ProHaswell, no support
Lenovo U330pHaswell, no support

“Support” refers to the presence of the Intel BG startup ACM module, the manifests mentioned above and the corresponding code in the BIOS, i.e. implementation for analysis.

As an example, take downloaded from the office. Site vendor image SPI flash memory for Gigabyte GA-H170-D3H (version F4).


Intel CPU boot ROM



First of all, let's talk about the actions of the processor in case Intel BG technology is enabled.

No samples of the decrypted microcode could be found, therefore, how the actions described below are implemented (in microcode or hardware) is an open question. Nevertheless, the fact that modern Intel processors "know how" to produce these actions is a fact.

After exiting the RESET state, the processor (into the address space of which the contents of the flash memory is already mapped) finds the FIT (Firmware Interface Table) table. It is easy to find, the pointer to it is written at FFFF FFC0h.


In this example, at this address is the value of FFD6 9500h. Turning to this address, the processor sees the FIT table, the contents of which are broken into records. The first entry is the header of the following structure:

 typedef struct FIT_HEADER { char Tag[8]; // '_FIT_ ' unsigned long NumEntries; // including FIT header entry unsigned short Version; // 1.0 unsigned char EntryType; // 0 unsigned char Checksum; };


For some unknown reason, the cheksum is far from always counted in these tables (the field is left zero).

The remaining entries indicate various binaries that need to be parsed / executed before the BIOS is executed, i.e. before switching to legacy RESET vector (FFFF FFF0h). The structure of each such record is as follows:

 typedef struct FIT_ENTRY { unsigned long BaseAddress; unsigned long : 32; unsigned long Size; unsigned short Version; // 1.0 unsigned char EntryType; unsigned char Checksum; };


The EntryType field indicates the type of block that this entry points to. We know several types:

 enum FIT_ENTRY_TYPES { FIT_HEADER = 0, MICROCODE_UPDATE, BG_ACM, BIOS_INIT = 7, TPM_POLICY, BIOS_POLICY, TXT_POLICY, BG_KEYM, BG_IBBM };

Now it is obvious that one of the entries points to the location of the Intel BG startup ACM binary. The header structure of this binary is typical for code modules developed by Intel (ACMs, microcode updates, Intel ME code sections, ...).

 typedef struct BG_ACM_HEADER { unsigned short ModuleType; // 2 unsigned short ModuleSubType; // 3 unsigned long HeaderLength; // in dwords unsigned long : 32; unsigned long : 32; unsigned long ModuleVendor; // 8086h unsigned long Date; // in BCD format unsigned long TotalSize; // in dwords unsigned long unknown1[6]; unsigned long EntryPoint; unsigned long unknown2[16]; unsigned long RsaKeySize; // in dwords unsigned long ScratchSize; // in dwords unsigned char RsaPubMod[256]; unsigned long RsaPubExp; unsigned char RsaSig[256]; };


The processor loads this binary into its cache, verifies and launches it.

Intel BG startup ACM


As a result of the analysis of this ACM, it became clear that he is doing the following:


To find these manifests, ACM also uses the FIT table, which has two types of records to point to these structures (see FIT_ENTRY_TYPES above).

Let us dwell on the manifestos. In the structure of the first manifest, we see several obscure constants, the public key hash from the second manifest, and the OEM Root Key public key with the signature in the form of a nested structure:

 typedef struct KEY_MANIFEST { char Tag[8]; // '__KEYM__' unsigned char : 8; // 10h unsigned char : 8; // 10h unsigned char : 8; // 0 unsigned char : 8; // 1 unsigned short : 16; // 0Bh unsigned short : 16; // 20h == hash size? unsigned char IbbmKeyHash[32]; // SHA256 of an IBBM public key BG_RSA_ENTRY OemRootKey; }; typedef struct BG_RSA_ENTRY { unsigned char : 8; // 10h unsigned short : 16; // 1 unsigned char : 8; // 10h unsigned short RsaPubKeySize; // 800h unsigned long RsaPubExp; unsigned char RsaPubKey[256]; unsigned short : 16; // 14 unsigned char : 8; // 10h unsigned short RsaSigSize; // 800h unsigned short : 16; // 0Bh unsigned char RsaSig[256]; };


To verify the public key of the OEM Root Key, we recall the SHA256 hash from fyuzov, which at this moment has already been received from Intel ME, is used.

We turn to the second manifest. It consists of three structures:

 typedef struct IBB_MANIFEST { ACBP Acbp; // Boot policies IBBS Ibbs; // IBB description IBB_DESCRIPTORS[]; PMSG Pmsg; // IBBM signature };

In the first - some constants:

 typedef struct ACBP { char Tag[8]; // '__ACBP__' unsigned char : 8; // 10h unsigned char : 8; // 1 unsigned char : 8; // 10h unsigned char : 8; // 0 unsigned short : 16; // x & F0h = 0 unsigned short : 16; // 0 < x <= 400h };

The second contains the SHA256 hash of IBB and the number of descriptors that describe the contents of IBB (that is, what the hash is considered to be from):

 typedef struct IBBS { char Tag[8]; // '__IBBS__' unsigned char : 8; // 10h unsigned char : 8; // 0 unsigned char : 8; // 0 unsigned char : 8; // x <= 0Fh unsigned long : 32; // x & FFFFFFF8h = 0 unsigned long Unknown[20]; unsigned short : 16; // 0Bh unsigned short : 16; // 20h == hash size ? unsigned char IbbHash[32]; // SHA256 of an IBB unsigned char NumIbbDescriptors; };

IBB descriptors follow this structure, one after the other. Their contents have the following format:

 typedef struct IBB_DESCRIPTOR { unsigned long : 32; unsigned long BaseAddress; unsigned long Size; };

Everything is simple: each descriptor contains the address / size of the IBB chunk. Thus, the concatenation of the blocks pointed to by these descriptors (in the order of the descriptors themselves) is IBB. And, as a rule, IBB is a combination of all modules of the SEC and PEI phases.

The second manifest completes the structure containing the IBB public key (verified by the SHA256 hash from the first manifest) and the signature of this manifest:

 typedef struct PMSG { char Tag[8]; // '__PMSG__' unsigned char : 8; // 10h BG_RSA_ENTRY IbbKey; };


So, even before the UEFI BIOS starts to run, the processor will launch ACM, which will verify the authenticity of the contents of the partitions with the SEC and PEI phase codes. Next, the processor exits the ACM, proceeds along the RESET vector and starts executing the BIOS.

A verified PEI partition must contain a module that checks the remaining BIOS (DXE code). This module is already developing IBV (Independent BIOS Vendor) or the system vendor itself. Since caught at our disposal and having Intel BG support, only Lenovo and Gigabyte systems turned out to be, consider the code extracted from these systems.

UEFI BIOS module LenovoVerifiedBootPei


In the case of Lenovo, this turned out to be the LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D} module developed by Lenovo.

His job is to search (by GUID) hash tables for DXE and DXE verification.

 if (EFI_PEI_SERVICES->GetBootMode() != BOOT_ON_S3_RESUME) { if (!FindHashTable()) return EFI_NOT_FOUND; if (!VerifyDxe()) return EFI_SECURITY_VIOLATION; }

The hash table {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} has the following format:

 typedef struct HASH_TABLE { char Tag[8]; // '$HASHTBL' unsigned long NumDxeDescriptors; DXE_DESCRIPTORS[]; }; 

 typedef struct DXE_DESCRIPTOR { unsigned char BlockHash[32]; // SHA256 unsigned long Offset; unsigned long Size; };

UEFI BIOS module BootGuardPei


In the case of Gigabyte, this turned out to be the BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066} module developed by AMI, therefore, present in any AMI BIOS with Intel BG support.

Its algorithm works somewhat differently, however, comes down to the same:

 int bootMode = EFI_PEI_SERVICES->GetBootMode(); if (bootMode != BOOT_ON_S3_RESUME && bootMode != BOOT_ON_FLASH_UPDATE && bootMode != BOOT_IN_RECOVERY_MODE) { HOB* h = CreateHob(); if (!FindHashTable()) return EFI_NOT_FOUND; WriteHob(&h, VerifyDxe()); return h; }

The hash table {389CC6F2-1EA8-467B-AB8A-78E769AE2A15}, which he is looking for, has the following format:

 typedef HASH_TABLE DXE_DESCRIPTORS[]; typedef struct DXE_DESCRIPTOR { unsigned char BlockHash[32]; // SHA256 unsigned long BaseAddress; unsigned long Size; };

Intel Boot Guard 2.x


Let us briefly describe another implementation of Intel Boot Guard, which was found in a newer Intel SoC-based system with Apollo Lake micro-architecture - ASRock J4205-IT.

Although this version will be used only in SoCs (new systems with Kaby Lake microarchitecture continue to use Intel Boot Guard 1.x), it is of great interest in exploring the new architecture for platforms on the Intel SoC, in which tangible changes have occurred, for example :



The content of the new IFWI region is a set of the following modules:
BiasNameDescription
0000 2000hSMIPSome kind of platform configuration, signed by the vendor
0000 6000hRBEPIntel TXE, x86 firmware code section, signed by Intel
0001 0000hPMCPIntel PMC firmware code section, ARC, signed by Intel
0002 0000hFTPRIntel TXE, x86 firmware code section, signed by Intel
0007 B000hUcodefirmware updates for CPU, signed by Intel
0008 0000hIBBPUEFI BIOS, SEC / PEI, x86 phases, signed by vendor
0021 8000hISHCIntel ISH firmware code section, x86, signed by vendor
0025 8000hNftpIntel TXE, x86 firmware code section, signed by Intel
0036 1000hIUNPunknown
0038 1000hOBBPUEFI BIOS, DXE phase, x86, not signed

When analyzing the TXE firmware, it became obvious that after RESET, TXE keeps the processor in this state until it prepares the basic contents of the address space for the CPU (FIT, ACM, RESET vector ...). Moreover, TXE places this data in its SRAM, after which it temporarily grants the processor access there and “releases” it from the RESET.

Guarding rootkits


Well, now move on to the "hot." Once we discovered that on many systems, SPI flash descriptors have permission to access SPI flash memory regions so that all users of this memory can write and read any region. Those. no way.

After checking with the MEinfo utility (from Intel STK), we saw that the manufacturing mode on these systems is not closed, therefore, the chipset fusions (FPFs) are left in an undefined state. Yes, Intel BG in such cases is neither turned on nor turned off.

We are talking about the following systems (with regards to Intel BG and what will be described later in the article, we will talk about systems with a Haswell microarchitecture and above):


Of course, we reported the discovery to these vendors, as well as to Intel.

Adequate reaction followed only from Lenovo , which recognized the problem and released the patch .

Gigabyte seemed to accept the information about the vulnerability, but did not comment.

Communication with MSI didn’t stop at our request to send in our open PGP key (to send them security advisory in encrypted form). They stated that “they are a hardware manufacturer and do not manufacture PGP keys”.

But more to the point. Since fyuzy left in an unspecified state, the user (or an attacker) can program them yourself (the most difficult thing is to find the Intel STK). This requires the following steps.

1. Boot into the Windows OS (in general, the actions described below can be done from under Linux, if you develop an analogue of the Intel STK under the desired OS). Using the MEinfo utility, make sure that the fyuza on this system is not programmed.


2. Read the contents of the flash memory using the Flash Programming Tool.


3. Open the read image using any UEFI BIOS editing tool, make the necessary changes (implement a rootkit, for example), create / edit existing KEYM and IBBM structures in the ME region.



The picture shows the public part of the RSA key, the hash of which will be programmed into the chipset fyuzas along with the rest of the Intel BG configuration.

4. Using the Flash Image Tool to build a new firmware image (setting the Intel BG configuration).


5. Write the new image to the flash memory using the Flash Programming Tool, verify with the MEinfo that the ME region now contains the Intel BG configuration.


6. Using the Flash Programming Tool, close the manufacturing mode.


7. The system will reboot, after which with MEinfo you can make sure that the FPFs are now programmed.


These actions will permanently enable Intel BG on this system. You will not be able to cancel the action, which means:


To understand what such a rootkit can do, you need to evaluate what makes it possible to execute your code in the UEFI BIOS environment. Say, in the most privileged processor mode, SMM. Such a rootkit can have the following properties:


Thus, this vulnerability allows an attacker to:




Although the capabilities of the Intel ISH subsystem have not yet been studied, it seems to be an interesting attack vector against Intel ME.

findings


  1. The study provided a technical description of the operation of the Intel Boot Guard technology. Minus a couple of secrets in the Intel-ovskoy model of security through obscurity.
  2. An attack scenario is presented that allows you to create a non-removable rootkit in the system.
  3. We saw that modern Intel processors are able to execute a lot of proprietary code even before the BIOS starts working.
  4. Platforms with Intel 64 architecture are becoming less suitable for running free software: hardware verification, an increasing number of proprietary technologies and subsystems (three cores in the SoC chipset: x86 ME, x86 ISH and ARC PMC).

Mitigations


Vendors who intentionally leave manufacturing mode open should definitely close it. So far, only eyes are closing and the new Kaby Lake systems show this.

Users can turn off Intel BG themselves on their systems (which are affected by the described vulnerability) by running the Flash Programming Tool with the -closemnf option. Previously, you should make sure (with the help of MEinfo) that the Intel BG configuration in the ME region provides for precisely turning off this technology after programming in FPFs.

Source: https://habr.com/ru/post/326556/

More articles:


All Articles