The security and privacy of customer data is a core priority for Azure and Windows. Encrypting data across different layers of device and transport is a universal technique to prevent exploits from accessing plaintext data. In Azure, we have a multitude of offerings to provide different levels of data confidentiality, encryption and isolation across workloads types (Azure Confidential Computing – Protect Data In Use | Microsoft Azure). One of such is VM memory encryption with Intel’s Total Memory Encryption – Multi Key (TME-MK), providing hardware accelerated encryption of DRAM. With the latest Intel 12^th Gen Core CPUs (Alder Lake) offering this capability, we are delighted to extend support in Windows 11 22H2 for TME-MK.

 

End-to-end Encryption

Encryption has long been an established mechanism to keep data from prying eyes. By encrypting data while it is at rest, in transit, and in use – we can prevent unexpected parties from getting access to sensitive information for the lifetime of data.

 

Data-at-rest is protected through (a plethora of) disk encryption technologies and data-in-transit is protected through network encryption protocols (SSL/TLS/HTTPS), both used in modern workloads for many years. Data-in-use protection has recently become available through the latest generation hardware in Azure, providing an end-to-end encryption schema. Memory encryption technology innovations are now becoming available in client CPUs.

 

PC Encryption Landscape

Windows 10 introduced Bitlocker to encrypt data while it is residing in persistent storage, ensuring that a stolen laptop does not result in exposure of customers’ saved files on disk. Attackers continually get more sophisticated and mount physical attacks to retrieve data from volatile memory mediums (i.e. DRAM). One example is using methods to cryogenically freeze memory which enables data to persist for long periods of time. Another example is setting up interposers which sit between the DRAM chip and the DRAM slot.

It is logical to extend cryptographic protection of data while it is in memory, but it is expensive to do entirely in software. In modern CPUs, hardware-accelerated capabilities (Intel Total Memory Encryption) are used where the memory controller encrypts data before it is committed to the DIMMs, and decrypt data when needs to be computed on. Having memory controller-accelerated encryption also has a nice property where workloads do not need to be specially modified to take advantage of this, and the operating system and hardware can transparently handle these operations.

 

Memory controller-based encryption prevents attackers who have physical access to DRAM from being able to read in-memory contents in plaintext. TME-MK extends that paradigm by enabling different VMs (partitions) to have unique memory encryption keys.

 

 

Total Memory Encryption – Multi Key (TME-MK)

TME-MK is available in Intel 3^rd Generation Xeon server processors and Intel 12^th Generation Core client processors. Azure, Azure Stack HCI, and now Windows 11 22H2 operating systems also take advantage of this new generation hardware feature. TME-MK is compatible with Gen 2 VM version 10 and newer. List of Guest OS’s supported in Gen 2

 

On Azure, customers that use DCsv3 and DCdsv3-series Azure Virtual Machines TME-MK.

 

TME-MK capabilities are also available starting with Azure Stack HCI 21H2 and Windows 11 22H2 TME-MK. Go to the Azure Stack HCI catalog and filter “VM memory encryption” to find Azure Stack HCI solutions that support TME-MK.

 

 

To boot a new VM with TME-MK protection (assigning it a unique encryption key from other partitions), use the following PowerShell cmdlet:

Set-VMMemory -VMName <name> -MemoryEncryptionPolicy EnabledIfSupported

 

To verify a running VM is enabled and using TME-MK for memory encryption, you can use the following Powershell cmdlet:

Get-VmMemory -VmName <name> | fl *

 

The following return value would describe a TME-MK protected VM:

MemoryEncryptionPolicy  : EnabledIfSupported

MemoryEncryptionEnabled : True

 

To learn more about syntax and parameters to boot VMs using powershell: New-VM (Hyper-V) | Microsoft Learn

Underneath the hood, the operating system will request the CPU to generate an ephemeral key (for the duration of the VM lifetime). This key will never leave the CPU (and not be visible even to the operating system or hypervisor). The hypervisor will then set the associated bits in the second level page tables (SLAT) describing the physical addresses associated with the VM that should be encrypted with said key by the memory controller when data moves to and from memory.

 

Conclusion

The privacy and security of customer data is top of mind for Windows 11.  Windows will continue to evolve and adopt modern defense-in depth capabilities to continue protecting our customers. For more information on Intel TME-MK, read Intel’s latest whitepaper: https://www.intel.com/content/www/us/en/architecture-and-technology/vpro/hardware-shield/total-memory-encryption-multi-key-white-paper.html

 

Windows OS Platform (Hyper-V Security) Team 

Jin Lin, Alexander Grest, Bruce Sherwin

 

In March 2020, we shared some preliminary information about a new security feature in Windows called Hardware-enforced Stack Protection based on Intel’s Control-flow Enforcement Technology (CET). Today, we are excited to share the next level of details with our developer community around protecting user-mode applications with this feature. Please see requirements section for hardware and OS requirements to take advantage of Hardware-enforced Stack Protection.

 

Starting from the 11C latest cumulative update for 20H1 (19041) and 20H2 (19042) versions of Windows 10, we’ve enabled user mode Hardware-enforced Stack Protection for supported hardware. This exploit mitigation will protect the return address, and work with other Windows mitigations to prevent exploit techniques that aim to achieve arbitrary code execution. When attackers find a vulnerability that allows them to overwrite values on the stack, a common exploit technique is to overwrite return addresses into attacker-defined locations to build a malicious payload. This technique is known as return-oriented programming (ROP). More details on ROP and hardware shadow stacks is in this kernel blog.

 

For user mode applications, this mitigation is opt-in, and the following details are intended to aid developers in understanding how to build protected applications. We will describe in detail the two policies in Hardware-enforced Stack Protection: 1) shadow stack 2) instruction pointer validation. Shadow stack hardens the return address and instruction pointer validation protects exception handling targets.

 

Shadow Stack

Shadow stack is a hardware-enforced read-only memory region that helps keep record of the intended control-flow of the program. On supported hardware, call instructions push the return address on both stacks and return instructions compare the values and issues a CPU exception if there is a return address mismatch. Due to these required hardware capabilities only newer processors will have this feature.

 

To enable shadow stack enforcement on an application, you only need to recompile the application with the /CETCOMPAT linker flag (available in Visual Studio 2019 16.7 Preview 4).

 

 

Generally, code changes are not needed and the only modification to the binary is a bit in the PE header. However, if your code behavior includes modifying the return addresses on the stack (which results in mismatch with the shadow stack), then the hijacking code must be removed.

 

Applications can also choose to dynamically enable shadow stack enforcement, by using the PROC_THREAD_ATTIBUTE_MITIGATION_POLICY attribute in CreateProcess. This allows programs with multiple executables with the same name to specify specific processes to enable enforcement.

 

Shadow stack enforcement by default is in compatibility mode. Compatibility mode provides a more flexible enforcement of shadow stacks, at module granularity. When a return address mismatch occurs in this mode, it is checked to see if 1) it is not in an image binary (from dynamic code) or 2) in a module that is not compiled for /CETCOMPAT. If either hold true, the execution is allowed to continue. This way, you can slowly increase the coverage of the mitigation, by compiling more modules with /CETCOMPAT at your own pace. To protect dynamic code in compatibility mode, there is a new API, SetProcessDynamicEnforcedCetCompatibleRanges, to allow you to specify a range of virtual addresses to enforce this mitigation. Note that by default this API can only be called from outside the target process for security purposes.

 

Note that all native 64-bit Windows DLLs are compiled with /CETCOMPAT.

 

Strict mode, by definition, strictly enforces shadow stack protections and will terminate the process if the intended return address is also not on the shadow stack.

 

Today, it is recommended to enable your application in compatibility mode, as third-party DLLs may be injected into your process, and subsequently perform return address hijacking. We are working with our ecosystem developers to clean up any of this behavior. At the current time, we recommend beginning by enabling compatibility mode enforcement for your application.

 

The following diagram illustrates how the system behaves under shadow stack. When a return address mismatch occurs, the CPU raises a #CP exception:

 

 

 

As you can see, return address mismatches cause a trap to the kernel, which comes with a performance hit even if the mismatch is forgiven and execution is allowed to continue.

 

Instruction Pointer Validation

With the presence of shadow stacks, one of the next exploit techniques attackers may use to hijack control flow is corrupting the instruction pointer value inside the CONTEXT structure passed into system calls that redirect the execution of a thread, such as NtContinue and SetThreadContext. To provide a comprehensive control-flow integrity mitigation, Hardware-enforced Stack Protection includes an additional mitigation to validate the instruction pointer during exception handling. It is important to keep this mitigation in mind as well when testing for compatibility.

 

When shadow stacks are enabled for an application, SetThreadContext is enlightened to validate the user-supplied instruction pointer. Calls are allowed to proceed only if the value is found on the shadow stack (otherwise the call will fail).

 

For structured exception handling, RtlRestoreContext/NtContinue is hardened by a parallel mitigation, EH Continuation Metadata (EHCONT), by using the /guard:ehcont flag.

 

 

When this flag is specified, the compiler will include metadata in the binary that has a table of valid exception handling continuation targets. The list of continuation targets is generated by the linker for compiled code. For dynamic code, continuation targets should be specified using SetProcessDynamicEHContinuationTargets (similarly can only be called from outside the target process by default). With this feature enabled, the user-supplied instruction pointer will be checked to see if it is 1) on the shadow stack or 2) in the EH continuation data, before allowing the call to proceed (otherwise the call will fail). Note that if the binary does not contain EHCONT data (legacy binary), then the call is allowed to proceed.

 

Additionally, an application can be compiled for EHCONT even without shadow stack protection, in which the user-supplied instruction pointer must be present in the EH continuation data.

 

Common Violations

To properly build your application for Hardware-enforced Stack Protection, ensure there is a good understanding of how these security mitigations are enforced. Since shadow stacks are present throughout the lifetime of the process, the test matrix is enabling the above mitigations and ensure all code paths do not violate the security guarantees. The goal is to ensure present application code does not perform any behavior deemed unsecure under these mitigations.

 

Here are some examples of behaviors that violate shadow stacks:

 

Certain code obfuscation techniques will not automatically work with shadow stacks. As mentioned above, CALL and RET are enlightened to push onto the shadow stack and perform return address comparisons. Instruction combinations like PUSH/RET will not work with shadow stacks, as the corresponding return address is not present on the shadow stack when RET is performed. One recommendation here is instead using a (Control flow guard protected) JMP instruction.

 

Additionally, techniques that manually return to a previous call frame that is not the preceding call frame will also need to be shadow stack aware. In this case, it is recommended to use the _incsspq intrinsic to pop return addresses off the shadow stack so that it is in sync with the call stack.

 

User Interfaces

There are some user interfaces to help you understand the state of enforcement of processes on the machine. In task manager, adding the “Hardware-enforced Stack Protection” column in the “Details” tab will indicate processes are shadow stack protected, and whether they are in compatibility (compatible modules only) or strict (all modules) mode.

 

 

Additionally, this mitigation can be controlled similar to other exploit protections, including toggling the enforcement using the Windows Defender UI, Group Policy, PowerShell, and other facilities. Use UserShadowStack and UserShadowStackStrictMode as the parameter keyword to manually toggle enforcement in compatibility and strict mode, respectively. Use AuditUserShadowStack to enable audit mode.

 

 

Requirements

You can begin building and testing your application to support Hardware-enforced Stack Protection today, by ensuring you have the following:

 

Hardware: 11^th Gen Intel Core Mobile processors and AMD Zen 3 Core (and newer)

Hardware-enforced Stack Protection capable OS: 19041.622 or 19042.622 and newer versions

 

Conclusion

We will continue to strive towards investing in exploit mitigations to make Windows 10 the most secure operating system. These mitigations will help proactively prohibit an attacker’s ability to hijack your program in the event a vulnerability is discovered. Note in the current release, this mitigation is only supported in 64-bit code. There is no support for 32-bit code, WoW64, or in Guest Virtual Machines at the moment.

 

In the latest canary builds of Edge (version 90), Hardware-enforced Stack Protection is enabled in compatibility mode on the browser and a few non-sandboxed processes. In upcoming releases, there will be continued investments in expanding the list of processes protected by this mitigation. Please try it out and provide your feedback. You can send related questions to [email protected].

 

 

Kernel Protection team - Jin Lin, Jason Lin, Matthew Woolman