MXCSR Configuration Dependent Timing

Introduction

The Data Operand Independent Timing Instruction Set Architecture (DOIT ISA) document describes a new feature  which in conjunction with our guidance on Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations can be used for “constant time” execution for code specifically written to the guidelines. This mode allows constant time code to inform the processor that data operand independent timing is needed.

On certain processors, MXCSR may also need to be configured to avoid data-dependent behavior for the instructions listed in Data Operand Independent Timing Instructions That May Exhibit MXCSR Configuration Dependent Timing Behavior. This article describes that behavior and configuration.

MXCSR Configuration Dependent Timing (MCDT)

On certain processors as listed in MCDT Enumeration, some data-independent timing vector instructions may have subtle data-dependent timing due to MXCSR configuration. Specifically, specific data values may delay instruction retirement by, at most, one cycle. This is a small enough delay that it may not be observable in common practice, but this small delay is still data-dependent timing. This data operand-dependent timing may impact software following Intel’s Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations.

Hardware

Future processors are not expected to exhibit data operand dependent timing due to MXCSR configuration. This will be enumerated by CPUID.(EAX=7H,ECX=2):EDX[5]=1. Many current processors which are also not affected are listed in the Processors That Do Not Exhibit MCDT Behavior section.

Software Mitigations

Some environments may conclude that this side channel is minor and does not need mitigation. 

For systems that do not enumerate CPUID.(EAX=7H,ECX=2):EDX[5]=1, software that does need mitigation can mitigate the data-dependent timing by loading MXCSR with the value of 0x1FBF before using data operand independent timing instructions impacted by the MXCSR configuration. Software must use pre- and post-serialized LDMXCSR instructions before using impacted data operand independent timing instructions.

Prolog:
STMXCSR save_val
LDMXCSR value_0x1fbf
LFENCE
// Constant-time code using affected instructions
Epilog:
LFENCE
LDMXCSR save_val

For applications that do not otherwise depend on a specific value of MXCSR, the value of 0x1FBF can be established during the initialization of the application and mitigate the data dependent timing with minimal overhead.

Instructions That May Exhibit MCDT Behavior

This list is based on Intel's investigation and is current as of the date of publication. Intel will update this list if additional instructions with these characteristics are discovered.

• PMADDUBSW
• PMULUDQ
• VPMULHRSW
• PMADDWD
• VPLZCNTD    
• VPMULHUW
• PMULDQ
• VPLZCNTQ
• VPMULHW
• PMULHRSW
• VPMADD52HUQ
• VPMULLD
• PMULHUW
• VPMADD52LUQ
• VPMULLQ
• PMULHW
• VPMADDUBSW
• VPMULLW
• PMULLD
• VPMADDWD
• VPMULUDQ
• PMULLW
• VPMULDQ

Intel^® Software Guard Extensions (Intel^® SGX)

Although instructions inside enclave mode will act as if data operand independent timing mode is set, they may still exhibit MCDT behavior.

If the intended operation of an Intel SGX enclave, for the lifetime of the enclave, is achievable with MXCSR=0x1FBF, then any loads of MXCSR (via LDMXCSR, XRSTOR, etc.) should be of 0x1FBF. There should also be an LFENCE between any load of MXCSR (even of 0x1FBF) and subsequent use of any affected instruction. 

If the enclave is compatible with MXCSR=0x1FBF and uses any of the affected instructions, then the beginning of each enclave ECALL should change MXCSR to 0x1FBF and then execute an LFENCE instruction. The Intel SGX SDK will be changed to do this.

The Intel-provided SGX architectural enclaves (AEs) fall into this compatible with MXCSR=0x1FBF category.

If the intended operation of an Intel SGX enclave is not achievable with MXCSR=0x1FBF, then the general sequence in the Software Mitigations section should be used instead.

Enumeration and Architectural MSRs

MCDT Enumeration

CPUID.(EAX=7H,ECX=2):EDX[5] enumerates MCDT_NO. Processors that enumerate this bit as 1  do not exhibit MCDT behavior and do not need to be mitigated. Note that Intel Atom and pre-Skylake Intel Core processors may not enumerate MCDT_NO but nevertheless do not exhibit MCDT behavior. Refer to the Processors That May Exhibit MCDT Behavior section and the Processors That Do Not Exhibit MCDT Behavior section for more infomation about these processors.

MCDT Enumeration Guidance for Cryptographic Software

CPUID leaf 7 subleaf 2 EDX bit 5 enumerates MCDT_NO. Processors that enumerate this bit as 1 do not exhibit MXCSR Configuration Dependent Timing behavior and do not need to mitigate it. Intel Atom and Intel Core processors based on microarchitectures prior to Skylake may not exhibit MCDT behavior despite not enumerating MCDT_NO. Refer to the Processors That Do Not Exhibit MCDT Behavior section for more information.

Cryptography developers who wish to apply MCDT mitigations should use the following steps to determine if MCDT mitigation should be applied:

The cryptography software should determine if MCDT_NO is enumerated as 1. If it is, then no mitigation needs to be applied.

If MCDT_NO is enumerated as 0, the cryptography software should determine if it is running in a virtualized environment by checking the value of CPUID leaf 1 ECX bit 31.

If CPUID leaf 1 ECX bit 31 is 0, then a hypervisor is not present, and the cryptography software should use CPUID family/model/stepping to determine if it is running on a processor documented as not exhibiting MCDT behavior. 

If CPUID leaf 1 ECX bit 31 is 1, then a hypervisor is present and the cryptography software may be running on a processor that does not exhibit MCDT behavior, regardless of the family/ model/stepping that is enumerated due to virtualization of CPUID.

VMM Guidance for Non-Migratable and Migratable VMs

For non-migratable VMs, VMM software should enumerate MCDT_NO  as 1 to a guest only if the host physical machine either enumerates MCDT_NO as 1 or a CPUID family/model/stepping that matches a processor documented to not exhibit MCDT behavior in the section Processors That Do Not Exhibit MCDT Behavior section.

For migratable VMs, VMM software should enumerate MCDT_NO as 1 only if every host physical machine that the VM may potentially migrate to either enumerates MCDT_NO as 1 or a CPUID family/model/stepping that matches a processor documented to not exhibit MCDT behavior in the Processors That Do Not Exhibit MCDT Behavior section.

Processors That May Exhibit MCDT Behavior

All Intel Core processors based on microarchitecture code named Skylake and later exhibit this behavior for at least one instruction from the list in the Example Instructions That May Exhibit MCDT Behavior section.

• Note that a limited number of future processors which are not on the above list of affected processors, may also exhibit MCDT behavior. They will not enumerate MCDT_NO. 
• Processors that may exhibit MCDT behavior include those based on microarchitectures code named Skylake server, Cascade Lake, Cooper Lake, Ice Lake server, Skylake, Kaby Lake, Coffee Lake, Whiskey Lake, Comet Lake, Ice Lake client, Lakefield, Tiger Lake, Rocket Lake, and Alder Lake.
• Processors that do not exhibit MCDT behavior include Intel Atom processors and Intel Core processors based on microarchitectures before Skylake.

Processors That Do Not Exhibit MCDT Behavior

Intel Core processors based on microarchitectures before Ice Lake and Intel Atom family processors based on microarchitectures before Gracemont do not exhibit MXCSR Dependent Timing behavior.