deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-23 14:23:38 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Move files and redirect

Browse Source
This commit is contained in:
Vinay Pamnani
2023-07-10 12:39:10 -04:00
parent be4ec89f8a
commit 11d4bb7d3b
17 changed files with 51 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

356
windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity.md Normal file
View File

@ -0,0 +1,356 @@
---
title: Enable memory integrity
description: This article explains the steps to opt in to using memory integrity on Windows devices.
ms.prod: windows-client
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.author: vinpa
author: vinaypamnani-msft
manager: aaroncz
audience: ITPro
ms.collection:
- highpri
- tier2
ms.topic: conceptual
ms.date: 03/16/2023
ms.reviewer:
ms.technology: itpro-security
---
# Enable virtualization-based protection of code integrity
**Applies to**
- Windows 10
- Windows 11
- Windows Server 2016 or higher
**Memory integrity** is a virtualization-based security (VBS) feature available in Windows. Memory integrity and VBS improve the threat model of Windows and provide stronger protections against malware trying to exploit the Windows kernel. VBS uses the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised. Memory integrity is a critical component that protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS. Memory integrity also restricts kernel memory allocations that could be used to compromise the system.
> [!NOTE]
> Memory integrity works better with Intel Kabylake and higher processors with *Mode-Based Execution Control*, and AMD Zen 2 and higher processors with *Guest Mode Execute Trap* capabilities. Older processors rely on an emulation of these features, called *Restricted User Mode*, and will have a bigger impact on performance.
> [!WARNING]
> Some applications and hardware device drivers may be incompatible with memory integrity. This incompatibility can cause devices or software to malfunction and in rare cases may result in a boot failure (blue screen). Such issues may occur after memory integrity has been turned on or during the enablement process itself. If compatibility issues occur, see [Troubleshooting](#troubleshooting) for remediation steps.
> [!NOTE]
> Memory integrity is sometimes referred to as *hypervisor-protected code integrity (HVCI)* or *hypervisor enforced code integrity*, and was originally released as part of *Device Guard*. Device Guard is no longer used except to locate memory integrity and VBS settings in Group Policy or the Windows registry.
## Memory integrity features
- Protects modification of the Control Flow Guard (CFG) bitmap for kernel mode drivers.
- Protects the kernel mode code integrity process that ensures that other trusted kernel processes have a valid certificate.
## How to turn on memory integrity
To enable memory integrity on Windows devices with supporting hardware throughout an enterprise, use any of these options:
- [Windows Security app](#windows-security-app)
- [Microsoft Intune (or another MDM provider)](#enable-memory-integrity-using-intune)
- [Group Policy](#enable-memory-integrity-using-group-policy)
- [Microsoft Configuration Manager](https://cloudblogs.microsoft.com/enterprisemobility/2015/10/30/managing-windows-10-device-guard-with-configuration-manager/)
- [Registry](#use-registry-keys-to-enable-memory-integrity)
### Windows Security app
**Memory integrity** can be turned on in the Windows Security app and found at **Windows Security** > **Device security** > **Core isolation details** > **Memory integrity**. For more information, see [Device protection in Windows Security](https://support.microsoft.com/help/4096339/windows-10-device-protection-in-windows-defender-security-center).
Beginning with Windows 11 22H2, the Windows Security app shows a warning if memory integrity is turned off. The warning indicator also appears on the Windows Security icon in the Windows Taskbar and in the Windows Notification Center. The user can dismiss the warning from within the Windows Security app.
To proactively dismiss the memory integrity warning, you can set the **Hardware_HVCI_Off** (DWORD) registry value under `HKLM\SOFTWARE\Microsoft\Windows Security Health\State` to 0. After you change the registry value, you must restart the device for the change to take effect.
### Enable memory integrity using Intune
Enabling in Intune requires using the Code Integrity node in the [VirtualizationBasedTechnology CSP](/windows/client-management/mdm/policy-csp-virtualizationbasedtechnology). You can configure these settings by using the [settings catalog](/mem/intune/configuration/settings-catalog).
### Enable memory integrity using Group Policy
1. Use Group Policy Editor (gpedit.msc) to either edit an existing GPO or create a new one.
2. Navigate to **Computer Configuration** > **Administrative Templates** > **System** > **Device Guard**.
3. Double-click **Turn on Virtualization Based Security**.
4. Select **Enabled** and under **Virtualization Based Protection of Code Integrity**, select **Enabled without UEFI lock**. Only select **Enabled with UEFI lock** if you want to prevent memory integrity from being disabled remotely or by policy update. Once enabled with UEFI lock, you must have access to the UEFI BIOS menu to turn off Secure Boot if you want to turn off memory integrity.
![Enable memory integrity using Group Policy.](../images/enable-hvci-gp.png)
5. Select **Ok** to close the editor.
To apply the new policy on a domain-joined computer, either restart or run `gpupdate /force` in an elevated command prompt.
### Use registry keys to enable memory integrity
Set the following registry keys to enable memory integrity. These keys provide exactly the same set of configuration options provided by Group Policy.
<!--This comment ensures that the Important above and the Warning below don't merge together. -->
> [!IMPORTANT]
>
> - Among the commands that follow, you can choose settings for **Secure Boot** and **Secure Boot with DMA**. In most situations, we recommend that you choose **Secure Boot**. This option provides Secure Boot with as much protection as is supported by a given computer's hardware. A computer with input/output memory management units (IOMMUs) will have Secure Boot with DMA protection. A computer without IOMMUs will simply have Secure Boot enabled.
>
> - If you select **Secure Boot with DMA**, memory integrity and the other VBS features will only be turned on for computers that support DMA. That is, for computers with IOMMUs only. Any computer without IOMMUs will not have VBS or memory integrity protection.
>
> - All drivers on the system must be compatible with virtualization-based protection of code integrity; otherwise, your system may fail. We recommend that you enable these features on a group of test computers before you enable them on users' computers.
#### For Windows 10 version 1607 and later and for Windows 11 version 21H2
Recommended settings (to enable memory integrity without UEFI Lock):
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Locked" /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Locked" /t REG_DWORD /d 0 /f
```
If you want to customize the preceding recommended settings, use the following registry keys.
**To enable VBS only (no memory integrity)**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f
```
**To enable VBS and require Secure boot only (value 1)**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f
```
**To enable VBS with Secure Boot and DMA (value 3)**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 3 /f
```
**To enable VBS without UEFI lock (value 0)**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Locked" /t REG_DWORD /d 0 /f
```
**To enable VBS with UEFI lock (value 1)**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Locked" /t REG_DWORD /d 1 /f
```
**To enable memory integrity**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 1 /f
```
**To enable memory integrity without UEFI lock (value 0)**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Locked" /t REG_DWORD /d 0 /f
```
**To enable memory integrity with UEFI lock (value 1)**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Locked" /t REG_DWORD /d 1 /f
```
**To gray out the memory integrity UI and display the message "This setting is managed by your administrator"**
```console
reg delete HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity /v "WasEnabledBy" /f
```
**To let memory integrity UI behave normally (Not grayed out)**
```console
reg add HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity /v "WasEnabledBy" /t REG_DWORD /d 2 /f
```
#### For Windows 10 version 1511 and earlier
Recommended settings (to enable memory integrity, without UEFI Lock):
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "HypervisorEnforcedCodeIntegrity" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Unlocked" /t REG_DWORD /d 1 /f
```
If you want to customize the preceding recommended settings, use the following settings.
**To enable VBS (it is always locked to UEFI)**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f
```
**To enable VBS and require Secure boot only (value 1)**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f
```
**To enable VBS with Secure Boot and DMA (value 3)**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 3 /f
```
**To enable memory integrity (with the default, UEFI lock)**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "HypervisorEnforcedCodeIntegrity" /t REG_DWORD /d 1 /f
```
**To enable memory integrity without UEFI lock**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Unlocked" /t REG_DWORD /d 1 /f
```
### Enable memory integrity using Windows Defender Application Control (WDAC)
You can use WDAC policy to turn on memory integrity using any of the following techniques:
1. Use the [WDAC Wizard](https://aka.ms/wdacwizard) to create or edit your WDAC policy and select the option **Hypervisor-protected Code Integrity** on the **Policy Rules** page of the Wizard.
2. Use the [Set-HVCIOptions](/powershell/module/configci/set-hvcioptions) PowerShell cmdlet.
3. Edit your WDAC policy XML and modify the value set for the `<HVCIOptions>` element.
> [!NOTE]
> If your WDAC policy is set to turn memory integrity on, it will be turned on even if the policy is in audit mode.
### Validate enabled VBS and memory integrity features
Windows 10, Windows 11, and Windows Server 2016 and higher have a WMI class for VBS-related properties and features: *Win32\_DeviceGuard*. This class can be queried from an elevated Windows PowerShell session by using the following command:
```powershell
Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard
```
> [!NOTE]
> Mode Based Execution Control property will only be listed as available starting with Windows 10 version 1803 and Windows 11 version 21H2. This value is reported for both Intel's *Mode-Based Execution Control* and AMD's *Guest Mode Execute Trap* capabilities.
The output of this command provides details of the available hardware-based security features and those features that are currently enabled.
#### AvailableSecurityProperties
This field helps to enumerate and report state on the relevant security properties for VBS and memory integrity.
Value | Description
-|-
**0.** | If present, no relevant properties exist on the device.
**1.** | If present, hypervisor support is available.
**2.** | If present, Secure Boot is available.
**3.** | If present, DMA protection is available.
**4.** | If present, Secure Memory Overwrite is available.
**5.** | If present, NX protections are available.
**6.** | If present, SMM mitigations are available.
**7.** | If present, MBEC/GMET is available.
**8.** | If present, APIC virtualization is available.
#### InstanceIdentifier
A string that is unique to a particular device and set by WMI.
#### RequiredSecurityProperties
This field describes the required security properties to enable VBS.
Value | Description
-|-
**0.** | Nothing is required.
**1.** | If present, hypervisor support is needed.
**2.** | If present, Secure Boot is needed.
**3.** | If present, DMA protection is needed.
**4.** | If present, Secure Memory Overwrite is needed.
**5.** | If present, NX protections are needed.
**6.** | If present, SMM mitigations are needed.
**7.** | If present, MBEC/GMET is needed.
#### SecurityServicesConfigured
This field indicates whether Windows Defender Credential Guard or memory integrity has been configured.
Value | Description
-|-
**0.** | No services are configured.
**1.** | If present, Windows Defender Credential Guard is configured.
**2.** | If present, memory integrity is configured.
**3.** | If present, System Guard Secure Launch is configured.
**4.** | If present, SMM Firmware Measurement is configured.
#### SecurityServicesRunning
This field indicates whether Windows Defender Credential Guard or memory integrity is running.
Value | Description
-|-
**0.** | No services running.
**1.** | If present, Windows Defender Credential Guard is running.
**2.** | If present, memory integrity is running.
**3.** | If present, System Guard Secure Launch is running.
**4.** | If present, SMM Firmware Measurement is running.
#### Version
This field lists the version of this WMI class. The only valid value now is **1.0**.
#### VirtualizationBasedSecurityStatus
This field indicates whether VBS is enabled and running.
Value | Description
-|-
**0.** | VBS isn't enabled.
**1.** | VBS is enabled but not running.
**2.** | VBS is enabled and running.
#### PSComputerName
This field lists the computer name. All valid values for computer name.
Another method to determine the available and enabled VBS features is to run msinfo32.exe from an elevated PowerShell session. When you run this program, the VBS features are displayed at the bottom of the **System Summary** section.
:::image type="content" alt-text="Virtualization-based security features in the System Summary of System Information." source="images/system-information-virtualization-based-security.png" lightbox="images/system-information-virtualization-based-security.png":::
## Troubleshooting
- If a device driver fails to load or crashes at runtime, you may be able to update the driver using **Device Manager**.
- If you experience a critical error during boot or your system is unstable after turning on memory integrity, you can recover using the Windows Recovery Environment (Windows RE).
1. First, disable any policies that are used to enable VBS and memory integrity, for example Group Policy.
2. Then, boot to Windows RE on the affected computer, see [Windows RE Technical Reference](/windows-hardware/manufacture/desktop/windows-recovery-environment--windows-re--technical-reference).
3. After logging in to Windows RE, set the memory integrity registry key to off:
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 0 /f
```
4. Finally, restart your device.
> [!NOTE]
> If you turned on memory integrity with UEFI lock, you will need to disable Secure Boot to complete the Windows RE recovery steps.
## Memory integrity deployment in virtual machines
Memory integrity can protect a Hyper-V virtual machine, just as it would a physical machine. The steps to enable memory integrity are the same from within the virtual machine.
Memory integrity protects against malware running in the guest virtual machine. It doesn't provide extra protection from the host administrator. From the host, you can disable memory integrity for a virtual machine:
```powershell
Set-VMSecurity -VMName <VMName> -VirtualizationBasedSecurityOptOut $true
```
### Requirements for running memory integrity in Hyper-V virtual machines
- The Hyper-V host must run at least Windows Server 2016 or Windows 10 version 1607.
- The Hyper-V virtual machine must be Generation 2, and running at least Windows Server 2016 or Windows 10.
- Memory integrity and [nested virtualization](/virtualization/hyper-v-on-windows/user-guide/nested-virtualization) can be enabled at the same time. To enable the Hyper-V role on the virtual machine, you must first install the Hyper-V role in a Windows nested virtualization environment.
- Virtual Fibre Channel adapters aren't compatible with memory integrity. Before attaching a virtual Fibre Channel Adapter to a virtual machine, you must first opt out of virtualization-based security using `Set-VMSecurity`.
- The AllowFullSCSICommandSet option for pass-through disks isn't compatible with memory integrity. Before configuring a pass-through disk with AllowFullSCSICommandSet, you must first opt out of virtualization-based security using `Set-VMSecurity`.

132
windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows.md Normal file
View File

@ -0,0 +1,132 @@
---
title: How a Windows Defender System Guard helps protect Windows 10
description: Windows Defender System Guard reorganizes the existing Windows 10 system integrity features under one roof. Learn how it works.
ms.reviewer:
manager: aaroncz
ms.author: vinpa
search.appverid: met150
ms.prod: windows-client
ms.localizationpriority: medium
author: vinaypamnani-msft
ms.date: 03/01/2019
ms.technology: itpro-security
ms.topic: conceptual
---
# Windows Defender System Guard: How a hardware-based root of trust helps protect Windows 10
To protect critical resources such as the Windows authentication stack, single sign-on tokens, the Windows Hello biometric stack, and the Virtual Trusted Platform Module, a system's firmware and hardware must be trustworthy.
Windows Defender System Guard reorganizes the existing Windows 10 system integrity features under one roof and sets up the next set of investments in Windows security. It's designed to make these security guarantees:
- Protect and maintain the integrity of the system as it starts up
- Validate that system integrity has truly been maintained through local and remote attestation
## Maintaining the integrity of the system as it starts
### Static Root of Trust for Measurement (SRTM)
With Windows 7, one of the means attackers would use to persist and evade detection was to install what is often referred to as a bootkit or rootkit on the system.
This malicious software would start before Windows started, or during the boot process itself, enabling it to start with the highest level of privilege.
With Windows 10 running on modern hardware (that is, Windows 8-certified or greater) a hardware-based root of trust helps ensure that no unauthorized firmware or software (such as a bootkit) can start before the Windows bootloader.
This hardware-based root of trust comes from the device's Secure Boot feature, which is part of the Unified Extensible Firmware Interface (UEFI).
This technique of measuring the static early boot UEFI components is called the Static Root of Trust for Measurement (SRTM).
As there are thousands of PC vendors that produce many models with different UEFI BIOS versions, there becomes an incredibly large number of SRTM measurements upon bootup.
Two techniques exist to establish trust here—either maintain a list of known 'bad' SRTM measurements (also known as a blocklist), or a list of known 'good' SRTM measurements (also known as an allowlist).
Each option has a drawback:
- A list of known 'bad' SRTM measurements allows a hacker to change just 1 bit in a component to create an entirely new SRTM hash that needs to be listed. This means that the SRTM flow is inherently brittle - a minor change can invalidate the entire chain of trust.
- A list of known 'good' SRTM measurements requires each new BIOS/PC combination measurement to be carefully added, which is slow.
Also, a bug fix for UEFI code can take a long time to design, build, retest, validate, and redeploy.
### Secure Launch—the Dynamic Root of Trust for Measurement (DRTM)
[Windows Defender System Guard Secure Launch](system-guard-secure-launch-and-smm-protection.md), first introduced in Windows 10 version 1809, aims to alleviate these issues by leveraging a technology known as the Dynamic Root of Trust for Measurement (DRTM).
DRTM lets the system freely boot into untrusted code initially, but shortly after launches the system into a trusted state by taking control of all CPUs and forcing them down a well-known and measured code path.
This has the benefit of allowing untrusted early UEFI code to boot the system, but then being able to securely transition into a trusted and measured state.
![System Guard Secure Launch.](images/system-guard-secure-launch.png)
Secure Launch simplifies management of SRTM measurements because the launch code is now unrelated to a specific hardware configuration. This means the number of valid code measurements is small, and future updates can be deployed more widely and quickly.
### System Management Mode (SMM) protection
System Management Mode (SMM) is a special-purpose CPU mode in x86 microcontrollers that handles power management, hardware configuration, thermal monitoring, and anything else the manufacturer deems useful.
Whenever one of these system operations is requested, a non-maskable interrupt (SMI) is invoked at runtime, which executes SMM code installed by the BIOS.
SMM code executes in the highest privilege level and is invisible to the OS, which makes it an attractive target for malicious activity. Even if System Guard Secure Launch is used to late launch, SMM code can potentially access hypervisor memory and change the hypervisor.
To defend against this, two techniques are used:
- Paging protection to prevent inappropriate access to code and data
- SMM hardware supervision and attestation
Paging protection can be implemented to lock certain code tables to be read-only to prevent tampering. This prevents access to any memory that hasn't been assigned.
A hardware-enforced processor feature known as a supervisor SMI handler can monitor the SMM and make sure it doesn't access any part of the address space that it isn't supposed to.
SMM protection is built on top of the Secure Launch technology and requires it to function.
In the future, Windows 10 will also measure this SMI Handler's behavior and attest that no OS-owned memory has been tampered with.
## Validating platform integrity after Windows is running (run time)
While Windows Defender System Guard provides advanced protection that will help protect and maintain the integrity of the platform during boot and at run time, the reality is that we must apply an "assume breach" mentality to even our most sophisticated security technologies. We can trust that the technologies are successfully doing their jobs, but we also need the ability to verify that they were successful in achieving their goals. For platform integrity, we can't just trust the platform, which potentially could be compromised, to self-attest to its security state. So Windows Defender System Guard includes a series of technologies that enable remote analysis of the device's integrity.
As Windows 10 boots, a series of integrity measurements are taken by Windows Defender System Guard using the device's Trusted Platform Module 2.0 (TPM 2.0). System Guard Secure Launch won't support earlier TPM versions, such as TPM 1.2. This process and data are hardware-isolated away from Windows to help ensure that the measurement data isn't subject to the type of tampering that could happen if the platform was compromised. From here, the measurements can be used to determine the integrity of the device's firmware, hardware configuration state, and Windows boot-related components, just to name a few.
![Boot time integrity.](images/windows-defender-system-guard-boot-time-integrity.png)
After the system boots, Windows Defender System Guard signs and seals these measurements using the TPM. Upon request, a management system like Intune or Microsoft Configuration Manager can acquire them for remote analysis. If Windows Defender System Guard indicates that the device lacks integrity, the management system can take a series of actions, such as denying the device access to resources.
[!INCLUDE [windows-defender-system-guard](../../../../includes/licensing/windows-defender-system-guard.md)]
## System requirements for System Guard
This feature is available for the following processors:
- Intel&reg; vPro&trade; processors starting with Intel&reg; Coffeelake, Whiskeylake, or later silicon
- AMD&reg; processors starting with Zen2 or later silicon
- Qualcomm&reg; processors with SD850 or later chipsets
### Requirements for Intel&reg; vPro&trade; processors starting with Intel&reg; Coffeelake, Whiskeylake, or later silicon
|Name|Description|
|--------|-----------|
|64-bit CPU|A 64-bit computer with minimum four cores (logical processors) is required for hypervisor and virtualization-based security (VBS). For more information about Hyper-V, see [Hyper-V on Windows Server 2016](/windows-server/virtualization/hyper-v/hyper-v-on-windows-server) or [Introduction to Hyper-V on Windows 10](/virtualization/hyper-v-on-windows/about/). For more information about hypervisor, see [Hypervisor Specifications](/virtualization/hyper-v-on-windows/reference/tlfs).|
|Trusted Platform Module (TPM) 2.0|Platforms must support a discrete TPM 2.0. Integrated/firmware TPMs aren't supported, except Intel chips that support Platform Trust Technology (PTT), which is a type of integrated hardware TPM that meets the TPM 2.0 spec.|
|Windows DMA Protection|Platforms must meet the Windows DMA Protection Specification (all external DMA ports must be off by default until the OS explicitly powers them).|
|SMM communication buffers| All SMM communication buffers must be implemented in EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types. |
|SMM Page Tables| Must NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory). <br/>Must NOT contain any mappings to code sections within EfiRuntimeServicesCode. <br/>Must NOT have execute and write permissions for the same page <br/>Must allow ONLY that TSEG pages can be marked executable and the memory map must report TSEG EfiReservedMemoryType. <br/>BIOS SMI handler must be implemented such that SMM page tables are locked on every SMM entry. |
|Modern/Connected Standby|Platforms must support Modern/Connected Standby.|
|TPM AUX Index|Platform must set up a AUX index with index, attributes, and policy that exactly corresponds to the AUX index specified in the TXT DG with a data size of exactly 104 bytes (for SHA256 AUX data). (NameAlg = SHA256) <br/> Platforms must set up a PS (Platform Supplier) index with: <ul><li> Exactly the "TXT PS2" style Attributes on creation as follows: <ul><li>AuthWrite</li><li>PolicyDelete</li><li>WriteLocked</li><li>WriteDefine</li><li>AuthRead</li><li>WriteDefine</li><li>NoDa</li><li>Written</li><li>PlatformCreate</li></ul> <li>A policy of exactly PolicyCommandCode(CC = TPM2_CC_UndefineSpaceSpecial) (SHA256 NameAlg and Policy)</li><li> Size of exactly 70 bytes </li><li> NameAlg = SHA256 </li><li> Also, it must have been initialized and locked (TPMA_NV_WRITTEN = 1, TPMA_NV_WRITELOCKED = 1) at time of OS launch. </li></ul> PS index data DataRevocationCounters, SINITMinVersion, and PolicyControl must all be 0x00 |
|AUX Policy|The required AUX policy must be as follows: <ul><li> A = TPM2_PolicyLocality (Locality 3 & Locality 4) </li><li>B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)</li><li>authPolicy = \{A} OR {{A} AND \{B}}</li><li>authPolicy digest = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59, 0xe9, 0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93, 0x0f, 0x4c, 0xb2, 0xcc, 0x5b, 0x97, 0x24</li></ul>|
|TPM NV Index|Platform firmware must set up a TPM NV index for use by the OS with: <ul><li>Handle: 0x01C101C0 </li><li>Attributes: <ul><li>TPMA_NV_POLICYWRITE</li><li>TPMA_NV_PPREAD </li><li>TPMA_NV_OWNERREAD</li><li>TPMA_NV_AUTHREAD</li><li>TPMA_NV_POLICYREAD</li><li>TPMA_NV_NO_DA</li><li>TPMA_NV_PLATFORMCREATE</li><li>TPMA_NV_POLICY_DELETE</li></ul> <li>A policy of: </li><ul><li>A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)</li><li>B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial) </li><li> authPolicy = \{A} OR {{A} AND \{B}} </li><li> Digest value of 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1 </li></ul></ul> |
|Platform firmware|Platform firmware must carry all code required to execute an Intel&reg; Trusted Execution Technology secure launch: <ul><li>Intel&reg; SINIT ACM must be carried in the OEM BIOS</li><li>Platforms must ship with a production ACM signed by the correct production Intel&reg; ACM signer for the platform</li></ul>|
|Platform firmware update|System firmware is recommended to be updated via UpdateCapsule in Windows Update. |
### Requirements for AMD&reg; processors starting with Zen2 or later silicon
|Name|Description|
|--------|-----------|
|64-bit CPU|A 64-bit computer with minimum four cores (logical processors) is required for hypervisor and virtualization-based security (VBS). For more information about Hyper-V, see [Hyper-V on Windows Server 2016](/windows-server/virtualization/hyper-v/hyper-v-on-windows-server) or [Introduction to Hyper-V on Windows 10](/virtualization/hyper-v-on-windows/about/). For more information about hypervisor, see [Hypervisor Specifications](/virtualization/hyper-v-on-windows/reference/tlfs).|
|Trusted Platform Module (TPM) 2.0|Platforms must support a discrete TPM 2.0 OR Microsoft Pluton TPM.|
|Windows DMA Protection|Platforms must meet the Windows DMA Protection Specification (all external DMA ports must be off by default until the OS explicitly powers them).|
|SMM communication buffers| All SMM communication buffers must be implemented in EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types. |
|SMM Page Tables| Must NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory). <br/>Must NOT contain any mappings to code sections within EfiRuntimeServicesCode. <br/>Must NOT have execute and write permissions for the same page <br/>BIOS SMI handler must be implemented such that SMM page tables are locked on every SMM entry. |
|Modern/Connected Standby|Platforms must support Modern/Connected Standby.|
|TPM NV Index|Platform firmware must set up a TPM NV index for use by the OS with: <ul><li>Handle: 0x01C101C0 </li><li>Attributes: <ul><li>TPMA_NV_POLICYWRITE</li><li>TPMA_NV_PPREAD </li><li>TPMA_NV_OWNERREAD</li><li>TPMA_NV_AUTHREAD</li><li>TPMA_NV_POLICYREAD</li><li>TPMA_NV_NO_DA</li><li>TPMA_NV_PLATFORMCREATE</li><li>TPMA_NV_POLICY_DELETE</li></ul> <li>A policy of: </li><ul><li>A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)</li><li>B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial) </li><li> authPolicy = \{A} OR {{A} AND \{B}} </li><li> Digest value of 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1 </li></ul></ul> |
|Platform firmware|Platform firmware must carry all code required to execute Secure Launch: <ul><li>AMD&reg; Secure Launch platforms must ship with AMD&reg; DRTM driver devnode exposed and the AMD&reg; DRTM driver installed</li></ul><br/>Platform must have AMD&reg; Secure Processor Firmware Anti-Rollback protection enabled <br/> Platform must have AMD&reg; Memory Guard enabled.|
|Platform firmware update|System firmware is recommended to be updated via UpdateCapsule in Windows Update. |
### Requirements for Qualcomm&reg; processors with SD850 or later chipsets
|Name|Description|
|--------|-----------|
|Monitor Mode Communication|All Monitor Mode communication buffers must be implemented in either EfiRuntimeServicesData (recommended), data sections of EfiRuntimeServicesCode as described by the Memory Attributes Table, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types|
|Monitor Mode Page Tables|All Monitor Mode page tables must: <ul><li>NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory) </li><li>They must NOT have execute and write permissions for the same page </li><li>Platforms must only allow Monitor Mode pages marked as executable </li><li>The memory map must report Monitor Mode as EfiReservedMemoryType</li><li>Platforms must provide mechanism to protect the Monitor Mode page tables from modification</li></ul> |
|Modern/Connected Standby|Platforms must support Modern/Connected Standby.|
|Platform firmware|Platform firmware must carry all code required to launch.|
|Platform firmware update|System firmware is recommended to be updated via UpdateCapsule in Windows Update. |

BIN
windows/security/hardware-security/images/secure-launch-group-policy.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 152 KiB

BIN
windows/security/hardware-security/images/secure-launch-msinfo.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 240 KiB

BIN
windows/security/hardware-security/images/secure-launch-registry.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

BIN
windows/security/hardware-security/images/secure-launch-security-app.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 47 KiB

BIN
windows/security/hardware-security/images/system-guard-secure-launch.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 88 KiB

BIN
windows/security/hardware-security/images/system-information-virtualization-based-security.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 82 KiB

BIN
windows/security/hardware-security/images/windows-defender-system-guard-boot-time-integrity.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

132
windows/security/hardware-security/kernel-dma-protection-for-thunderbolt.md Normal file
View File

@ -0,0 +1,132 @@
---
title: Kernel DMA Protection
description: Learn how Kernel DMA Protection protects Windows devices against drive-by Direct Memory Access (DMA) attacks using PCI hot plug devices.
ms.prod: windows-client
author: vinaypamnani-msft
ms.author: vinpa
manager: aaroncz
ms.collection:
- highpri
- tier1
ms.topic: conceptual
ms.date: 03/30/2023
ms.technology: itpro-security
appliesto:
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 10 and later</a>
---
# Kernel DMA Protection
Kernel DMA Protection is a Windows security feature that protects against external peripherals from gaining unauthorized access to memory.
PCIe hot plug devices such as Thunderbolt, USB4, and CFexpress allow users to attach classes of external peripherals, including graphics cards, to their devices with the plug-and-play ease of USB.\
These devices are DMA-capable, and can access system memory and perform read and write operations without the need for the system processor's involvement. This capability is the reason behind the exceptional performance of PCI devices, but it also makes them susceptible to *drive-by DMA attacks*.
Drive-by DMA attacks are attacks that occur while the owner of the system isn't present and usually take just a few minutes, with simple-to-moderate attacking tools (affordable, off-the-shelf hardware and software), that don't require the disassembly of the device. For example, attackers can plug in a USB-like device while the device owner is on a break, and walk away with all the secrets on the machine, or inject a malware that allows them to have full control over the device remotely while bypassing the lock screen.
> [!NOTE]
> Kernel DMA Protection feature doesn't protect against DMA attacks via 1394/FireWire, PCMCIA, CardBus, or ExpressCard.
## How Windows protects against DMA drive-by attacks
Windows uses the system *Input/Output Memory Management Unit (IOMMU)* to block external peripherals from starting and performing DMA, unless the drivers for these peripherals support memory isolation (such as DMA-remapping).
Peripherals with [DMA Remapping compatible drivers][LINK-1] will be automatically enumerated, started, and allowed to perform DMA to their assigned memory regions.
By default, peripherals with DMA Remapping incompatible drivers will be blocked from starting and performing DMA until an authorized user signs into the system or unlocks the screen. IT administrators can modify the default behavior applied to devices with DMA Remapping incompatible drivers using MDM or group policies.
## User experience
When Kernel DMA Protection is enabled:
- Peripherals with DMA Remapping-compatible device drivers will be automatically enumerated and started
- Peripherals with DMA Remapping-incompatible drivers will be blocked from starting if the peripheral was plugged in before an authorized user logs in, or while the screen is locked. Once the system is unlocked, the peripheral driver will be started by the OS, and the peripheral will continue to function normally until the system is rebooted, or the peripheral is unplugged. The peripheral will continue to function normally if the user locks the screen or signs out of the system.
[!INCLUDE [kernel-direct-memory-access-dma-protection](../../../includes/licensing/kernel-direct-memory-access-dma-protection.md)]
## System compatibility
Kernel DMA Protection requires UEFI firmware support, and Virtualization-based Security (VBS) isn't required.
Kernel DMA Protection isn't compatible with other BitLocker DMA attacks countermeasures. It's recommended to disable the BitLocker DMA attacks countermeasures if the system supports Kernel DMA Protection. Kernel DMA Protection provides higher security bar for the system over the BitLocker DMA attack countermeasures, while maintaining usability of external peripherals.
> [!NOTE]
> DMA remapping support for graphics devices was added in Windows 11 with the WDDM 3.0 driver model; Windows 10 doesn't support this feature.
## Check if Kernel DMA Protection is enabled
Systems that support Kernel DMA Protection will enable the feature automatically, with no user or IT admin configuration required.
You can use the Windows Security app to check if Kernel DMA Protection is enabled:
1. Open Windows Security app
1. Select **Device security > Core isolation details > Memory access protection**
:::image type="content" source="images/kernel-dma-protection-security-center.png" alt-text="Screenshot of Kernel DMA protection in Windows Security." lightbox="images/kernel-dma-protection-security-center.png" border="true":::
Alternatively, you can use the System Information desktop app (`msinfo32.exe`). If the system supports Kernel DMA Protection, the **Kernel DMA Protection** value will be set to **ON**.
:::image type="content" source="images/kernel-dma-protection.png" alt-text="Screenshot of Kernel DMA protection in System Information." lightbox="images/kernel-dma-protection.png" border="true":::
If the current state of **Kernel DMA Protection** is **OFF** and **Hyper-V - Virtualization Enabled in Firmware** is **NO**:
- Reboot into UEFI settings
- Turn on Intel Virtualization Technology
- Turn on Intel Virtualization Technology for I/O (VT-d)
- Reboot system into Windows
> [!NOTE]
> If the **Hyper-V** Windows feature is enabled, all the Hyper-V-related features will be hidden, and **A hypervisor has been detected. Features required for Hyper-V will not be displayed** entity will be shown at the bottom of the list. It means that **Hyper-V - Virtualization Enabled in Firmware** is set to **YES**.
>
> Enabling Hyper-V virtualization in Firmware (IOMMU) is required to enable **Kernel DMA Protection**, even when the firmware has the flag of *ACPI Kernel DMA Protection Indicators* described in [Kernel DMA Protection (Memory Access Protection) for OEMs][LINK-3].
If the state of **Kernel DMA Protection** remains Off, then the system doesn't support Kernel DMA Protection.
For systems that don't support Kernel DMA Protection, refer to the [BitLocker countermeasures](bitlocker/bitlocker-countermeasures.md) or [Thunderbolt 3 and Security on Microsoft Windows Operating system][EXT-1] for other means of DMA protection.
## Frequently asked questions
### Does Kernel DMA Protection prevent drive-by DMA attacks during Boot?
No, Kernel DMA Protection only protects against drive-by DMA attacks after the OS is loaded. It's the responsibility of the system firmware/BIOS to protect against attacks via the Thunderbolt 3 ports during boot.
### How can I check if a certain driver supports DMA-remapping?
Not all devices and drivers support DMA-remapping. To check if a specific driver is opted into DMA-remapping, check the values corresponding to the DMA Remapping Policy property in the Details tab of a device in Device Manager*. A value of **0** or **1** means that the device driver doesn't support DMA-remapping. A value of **2** means that the device driver supports DMA-remapping. If the property isn't available, then the device driver doesn't support DMA-remapping.
Check the driver instance for the device you're testing. Some drivers may have varying values depending on the location of the device (internal vs. external).
:::image type="content" source="images/device-details.png" alt-text="Screenshot of device details for a Thunderbolt controller showing a value of 2." border="false":::
### When the drivers for PCI or Thunderbolt 3 peripherals don't support DMA-remapping?
Use the Windows-provided drivers for the peripherals, when available. If there are no class drivers provided by Windows for your peripherals, contact your peripheral vendor/driver vendor to update the driver to support [DMA Remapping][LINK-1].
### My system's Kernel DMA Protection is off. Can DMA-remapping for a specific device be turned on?
Yes. DMA remapping for a specific device can be turned on independent from Kernel DMA Protection. For example, if the driver opts in and VT-d (Virtualization Technology for Directed I/O) is turned on, then DMA remapping will be enabled for the devices driver even if Kernel DMA Protection is turned off.
Kernel DMA Protection is a policy that allows or blocks devices to perform DMA, based on their remapping state and capabilities.
### Do Microsoft drivers support DMA-remapping?
The Microsoft inbox drivers for USB XHCI (3.x) Controllers, Storage AHCI/SATA Controllers, and Storage NVMe Controllers support DMA Remapping.
### Do drivers for non-PCI devices need to be compatible with DMA-remapping?
No. Devices for non-PCI peripherals, such as USB devices, don't perform DMA, thus no need for the driver to be compatible with DMA Remapping.
### How can an enterprise enable the External device enumeration policy?
The External device enumeration policy controls whether to enumerate external peripherals that aren't compatible with DMA-remapping. Peripherals that are compatible with DMA-remapping are always enumerated. Peripherals that aren't, can be blocked, allowed, or allowed only after the user signs in (default).
The policy can be enabled by using:
- Group Policy: **Administrative Templates\System\Kernel DMA Protection\Enumeration policy for external devices incompatible with Kernel DMA Protection**
- Mobile Device Management (MDM): [DmaGuard policies][LINK-2]
<!--links-->
[LINK-1]: /windows-hardware/drivers/pci/enabling-dma-remapping-for-device-drivers
[LINK-2]: /windows/client-management/mdm/policy-csp-dmaguard#dmaguard-policies
[LINK-3]: /windows-hardware/design/device-experiences/oem-kernel-dma-protection
[EXT-1]: https://thunderbolttechnology.net/security/Thunderbolt%203%20and%20Security.pdf

82
windows/security/hardware-security/system-guard-secure-launch-and-smm-protection.md Normal file
View File

@ -0,0 +1,82 @@
---
title: System Guard Secure Launch and SMM protection
description: Explains how to configure System Guard Secure Launch and System Management Mode (SMM protection) to improve the startup security of Windows 10 devices.
search.appverid: met150
ms.prod: windows-client
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
author: vinaypamnani-msft
ms.date: 11/30/2021
ms.reviewer:
manager: aaroncz
ms.author: vinpa
ms.technology: itpro-security
ms.topic: conceptual
---
# System Guard Secure Launch and SMM protection
**Applies to:**
- Windows 11
- Windows 10
This topic explains how to configure [System Guard Secure Launch and System Management Mode (SMM) protection](/windows/security/threat-protection/windows-defender-system-guard/how-hardware-based-root-of-trust-helps-protect-windows) to improve the startup security of Windows 10 and Windows 11 devices. The information below is presented from a client perspective.
> [!NOTE]
> System Guard Secure Launch feature requires a supported processor. For more information, see [System requirements for System Guard](how-hardware-based-root-of-trust-helps-protect-windows.md#system-requirements-for-system-guard).
## How to enable System Guard Secure Launch
You can enable System Guard Secure Launch by using any of these options:
- [Mobile Device Management (MDM)](#mobile-device-management)
- [Group Policy](#group-policy)
- [Windows Security app](#windows-security-app)
- [Registry](#registry)
### Mobile Device Management
System Guard Secure Launch can be configured for Mobile Device Management (MDM) by using DeviceGuard policies in the Policy CSP, [DeviceGuard/ConfigureSystemGuardLaunch](/windows/client-management/mdm/policy-csp-deviceguard#deviceguard-configuresystemguardlaunch).
### Group Policy
1. Click **Start** > type and then click **Edit group policy**.
2. Click **Computer Configuration** > **Administrative Templates** > **System** > **Device Guard** > **Turn On Virtualization Based Security** > **Secure Launch Configuration**.
![Secure Launch Configuration.](images/secure-launch-group-policy.png)
### Windows Security app
Click **Start** > **Settings** > **Update & Security** > **Windows Security** > **Open Windows Security** > **Device security** > **Core isolation** > **Firmware protection**.
![Windows Security app.](images/secure-launch-security-app.png)
### Registry
1. Open Registry editor.
2. Click **HKEY_LOCAL_MACHINE** > **SYSTEM** > **CurrentControlSet** > **Control** > **DeviceGuard** > **Scenarios**.
3. Right-click **Scenarios** > **New** > **Key** and name the new key **SystemGuard**.
4. Right-click **SystemGuard** > **New** > **DWORD (32-bit) Value** and name the new DWORD **Enabled**.
5. Double-click **Enabled**, change the value to **1**, and click **OK**.
![Secure Launch Registry.](images/secure-launch-registry.png)
## How to verify System Guard Secure Launch is configured and running
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**.
![Verifying Secure Launch is running in the Windows Security app.](images/secure-launch-msinfo.png)
> [!NOTE]
> To enable System Guard Secure launch, the platform must meet all the baseline requirements for [System Guard](/windows/security/threat-protection/windows-defender-system-guard/how-hardware-based-root-of-trust-helps-protect-windows), [Device Guard](../device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md), [Credential Guard](../../identity-protection/credential-guard/credential-guard-requirements.md), and [Virtualization Based Security](/windows-hardware/design/device-experiences/oem-vbs).
> [!NOTE]
> For more information around AMD processors, see [Microsoft Security Blog: Force firmware code to be measured and attested by Secure Launch on Windows 10](https://www.microsoft.com/security/blog/2020/09/01/force-firmware-code-to-be-measured-and-attested-by-secure-launch-on-windows-10/).