For developers implementing cryptographic algorithms, it is important to select instructions whose execution time is data-independent in order to mitigate timing side channels. Intel has provided guidance for developing “constant time” code, such as by addressing the “constant cycle” code in Intel’s Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations. This document provides guidance for a list of the instructions that have data-independent timing that can be used in conjunction with the previous guidelines. The mitigations and guidance in this document are based on Intel’s information and understanding at the time of writing, but as with other security guidance, is subject to change as the threat landscape evolves or new information becomes available. This document introduces a data operand independent timing processor mode on certain processors. Software can use this mode to enable data operand independent timing on a per-thread or per-process basis. Future enhancements may allow more fine-grain user mode control inside an application or library. Lastly, on certain processors, MXCSR may also need to be configured to avoid data-dependent behavior for certain instructions.
Note that these data operand independent timing instructions may have variable latency for reasons unrelated to the data values (for example, loading data from memory or the encoding of the instruction). Furthermore, an instruction being included on this list does not mean that its usage is resistant to power, thermal, or frequency-based side channels. Guidance to avoid these specific types of side channels will be provided separately in the future.
Instructions with Data Operand Independent Timing (DOIT)
Data Values vs. Address Values
The latency of a data operand independent timing instruction does not depend on the data values on which it operates. However, the latency of these instructions that fetch data from memory may vary based on the memory address that the load accesses to get that data. For example, an ADD R9, [RAX] instruction will load data from the address specified by RAX and will add that data loaded to R9. Because ADD is a data operand independent timing instruction, its latency will not be affected by the value of R9 or the value loaded from memory. However, it may be possible to determine the value of RAX (for example, via a cache side channel) as that data is being used to affect the memory access pattern of the program. Similarly, the instructions listed below will have execution time that is invariant regardless of the data value that is stored, but which may reveal the address to which they are storing that data.
Instruction Encodings and Immediate Values
Anything that changes the code bytes of an instruction may impact the latency of that instruction. For example, an instruction may have different latency if:
- It has a different immediate value.
- It uses a different memory addressing mode (for example, just a base register instead of having both a base and index register) even when the address being accessed is the same.
- It uses different registers (for example, RAX vs. AX vs. RBX) or different condition code (such as CF vs. ZF).
Masked operations have mask registers as inputs to the instruction. For example, certain Intel® Advanced Vector Extensions 512 (Intel® AVX-512) operations take a K mask register input. Some non-Intel AVX-512 operations (such as VMASKMOV, MASKMOVDQU, Gather, among others) have a mask register that is not a K mask register. For masked operations that do not access memory, the instruction latency will be invariant with respect to the mask register value.
For masked operations that access memory, the mask register (whether a K mask register or a separate register) may affect which memory addresses are accessed. Therefore, data operand independent timing instructions may have different effects on performance for different mask register values if they read or write to memory.
Data Operand Independent Timing Mode (DOITM)
To support use cases such as constant time code, a new model specific register (MSR) control enables data operand independent timing for the listed data operand independent timing instructions.
Specifically, when data operand independent timing mode is enabled, instructions within the data operand independent timing subset execute with timing (in terms of processor cycles) that is independent of the data values in the sources of the instruction, except for potential timing differences due to power or thermal variations. Moreover, while in data operand independent timing mode, the data values operated on by these data independent instructions will not impact the timing of other instructions. This property is true regardless of the status of data operand independent timing mode when the other instructions are executed.
When an instruction outside of the data operand independent timing subset or outside of the data operand independent timing mode is executed (either speculatively or non-speculatively), the data values operated on could potentially affect the timing both of the instruction operating on the data and of other instructions. Additionally, power consumed, CPU frequency, and telemetry recorded (such as performance monitoring events or running average power limit (RAPL) power measurements1) may differ based on the data values operated on within data operand independent timing mode. It is also possible that subsystems outside the core may implement data operand dependent features that may impact the timing in a data-dependent manner for data independent instructions.
Developers handling secret data that should only ever be processed in a data operand independent timing manner may need to consider speculative execution vulnerabilities. These vulnerabilities may cause the secret data to be handled in a data operand dependent manner and the developer may need to apply additional mitigations. Refer to Mitigating Timing Side Channels Against Cryptographic Implementations.
Data Operand Independent Timing Mode Controls
IA32_UARCH_MISC_CTL[DOITM] is a data operand independent timing mode control mechanism that restricts non-data operand independent timing behavior for the listed instructions. A processor supports IA32_UARCH_MISC_CTL[DOITM] if IA32_ARCH_CAPABILITIES is 1.
|Register Address Hex||Register Address Dec||Register Name /
|10AH||266||IA32_ARCH_CAPABILITIES||Enumeration of Architectural Features (RO)||If CPUID.(EAX-07H, ECX=0):EDX=1|
|10AH||266||12||DOITM: The processor supports data operand independent timing mode.|
For Intel® Core™ family processors based on microarchitectures before Ice Lake and Intel Atom® family processors based on microarchitectures before Gracemont that do not enumerate IA32_UARCH_MISC_CTL, developers may assume that the instructions listed here operate as if DOITM is enabled.
Intel Core family processors based on Ice Lake and later, such as Tiger Lake, Lakefield, and Rocket Lake will enumerate DOITM. Intel Atom family processors based on Gracemont and later will also enumerate DOITM. Refer to the Enumeration and Architectural MSRs section for more information.
On certain processors, microcode updates may need to be loaded for IA32_UARCH_MISC_CTL to be enumerated.
Software can enable data operand independent timing operation on a logical processor by setting IA32_UARCH_MISC_CTL[DOITM] to 1. Setting DOITM to 1 may impact performance, and that impact may vary in future processor generations.
Users should evaluate their threat model to decide whether this is a significant threat to their applications and then ask the operating system to only deploy DOIT mode to applications that they deem necessary. Note that DOIT mode is not expected to significantly improve resistance to side channel attacks unless the software was carefully written to avoid such attacks (specifically, following the guidance in Intel’s Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations).
Operating systems may wish to support IA32_UARCH_MISC_CTL in a manner similar to speculative store bypass disable.
Interactions with Other Modes of Operation
Interactions with Intel® Software Guard Extensions (Intel® SGX)
While executing inside enclave mode, processors that enumerate support for DOITM will enable data operand independent timing mode irrespective of the settings that control the mode.
Interactions with Intel® Trust Domain Extension (Intel® TDX)
There are no special interactions or interactions between data operand independent timing mode and Secure Arbitration Mode-Virtual Machines Extensions (SEAM VMX) operation. In particular, the enabling of data operand independent timing mode is not impacted while operating in SEAM VMX mode.
The DOIT mode control will be made visible to trust domains (TDs) and the Intel TDX module will context switch the control between TDs.
On certain processors, 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-dependent timing may occur even when DOIT mode is enumerated and enabled. This data operand-dependent timing may impact software following Intel’s Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations.
Future processors are expected to not exhibit data operand dependent timing due to MXCSR configuration. This will be enumerated by CPUID.(EAX=7H,ECX=2):EDX=1. Many current processors which are also not affected are listed in the Processors That Do Not Exhibit MCDT Behavior section.
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=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.
This list is based on Intel's reasonable investigation and is current as of the date of publication. Intel will update this list if additional instructions with these characteristics are discovered.
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.
CPUID.(EAX=7H,ECX=2):EDX 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 later sections, Processors That May Exhibit MCDT Behavior and Processors That Do Not Exhibit MCDT Behavior.
IA32_ARCH_CAPABILITIES enumerates support for the IA32_UARCH_MISC_CTL MSR (addr 0x1B01) and bit 0 of that MSR (DOITM). This bit implements a data operand independent timing mode. This enumeration bit is called Data Operand Independent Timing Mode (DOITM).
Processors that do not enumerate IA32_ARCH_CAPABILITIES[DOITM] when the latest microcode is applied do not need to set IA32_UARCH_MISC_CTL [DOITM] in order to have the behavior described in this document, although they may be affected by MXCSR Configuration Dependent Timing (MCDT) as described in the MXCSR Configuration Dependent Timing (MCDT) section.
IA32_UARCH_MISC_CTL MSR Definition
|Register Address Hex||Register Name / Bit Fields||Permission||Bit Description||Comment|
|1B01H||0||R/W||Data Operand Independent Timing Mode (DOITM)||If IA32_ARCH_CAPABILITIES[DOITM]=1|
This MSR is logical processor scoped and has a reset value of 0. When the DOITM bit is set in IA_32_UARCH_MISC_CTL, the processor enables Data Operand Independent Timing Mode.
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. See 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_NO2 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 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.
Intel Core processors based on microarchitecture code named Skylake and later exhibit this behavior for at least one instruction from the list in the Instructions That May Exhibit MCDT Behavior section.
|Processor||Stepping (All unless otherwise noted)||Code Name (s) / Microarchitecture (s)||Product Family|
|06_4EH||3||1. Skylake Y
2. Skylake U
3. Skylake U23e
|6th Generation Intel® Core™ Processor Family|
|06_55H||3, 4||1. Skylake Server
2. Skylake D, Bakerville
3. Skylake W
4. Skylake X
|1. Intel® Xeon® Scalable processor family
2. Intel® Xeon® D processor family
3. Intel® Xeon® W processor family
4. Intel® Core™ X-series Processors
|06_55H||6.7||1. Cascade Lake Server
2. Cascade Lake W
3. Cascade Lake X
|1. 2nd Generation Intel® Xeon® Scalable processor family
2. Intel® Xeon® W processor family
3. Intel® Core™ X-series Processor
|06_55H||<=B||Cooper Lake||3rd Generation Intel® Xeon® Scalable processor family|
|06_5EH||3||1. Skylake Xeon E3
2. Skylake H
3. Skylake S
|1. Intel® Xeon® E processor family
2, 3. 6th Generation Intel® Core™ Processor Family
|06_6AH||4,5,6||Ice Lake Xeon-SP||3rd Gen Intel® Xeon® Scalable processor family|
|06_6CH||1||Ice Lake D||Intel® Xeon® D Processor|
|06_7EH||5||Ice Lake U,Y||10th Generation Intel® Core™ Processor Family|
|06_8AH||1||Lakefield B-step||Intel® Core™ Processors with Intel® Hybrid Technology|
|06_8CH||1,2||Tiger Lake U
Tiger Lake U Refresh
Tiger Lake H35
|11th Generation Intel® Core™ Processor Family|
|06_8DH||1||Tiger Lake H||11th Generation Intel® Core™ Processor Family
Intel® Xeon® Processor Family
|06_8EH||9||1. Amber Lake-Y
2. Kaby Lake U
3. Kaby Lake U23e
4. Kaby Lake Y
|1. 8th Generation Intel® Core™ Processor Family
2,3,4. 7th Generation Intel® Core™ Processor Family
|06_8EH||A||Coffee Lake U43e
Kaby Lake Refresh U
|8th Generation Intel® Core™ Processor Family|
|06_8EH||B,C||1. Whiskey Lake U
2,3,4. Comet Lake U42
5. Amber Lake Y
|1. 8th Generation Intel® Core™ Processors
2. 10th Generation Intel® Core™ Processor Family
3. Intel® Pentium® Gold Processor Series
4. Intel® Celeron® Processor 5000 Series
5. 10th Generation Intel® Core™ Processor Family
|06_97H||2, 5||Alder Lake S||12th Generation Intel® Core™ Processor Family|
|06_9AH||3||1. Alder Lake H
2. Alder Lake P
|1. 12th Generation Intel® Core™ Processor Family
2. 12th Generation Intel® Core™ Processor Family
|06_9AH||4||Alder Lake U||12th Generation Intel® Core™ Processor Family
Intel® Pentium® Gold Processor Family
Intel® Celeron® Processor Family
|06_9EH||9||1. Kaby Lake S
2. Kaby Lake H
3. Kaby Lake G
4. Kaby Lake X
5. Kaby Lake Xeon E3
|1. 7th Generation Intel® Core™ Processor Family
2. 7th Generation Intel® Core™ Processor Family
3. 8th Generation Intel® Core™ Processor Family
Intel® Pentium® Processor Family
4. Intel® Core™ X-series Processors
5. Intel® Xeon® E processor family
|06_9EH||A, B, C, D||1. Coffee Lake H
2. Coffee Lake Xeon E
3. Coffee Lake S Xeon E
4. Coffee Lake S x/KBP
5. Coffee Lake S
|1. 8th Generation Intel® Core™ Processor Family
2. Intel® Xeon® E processor family
3. Intel® Xeon® E processor family
4. 8th Generation Intel® Core™ Processor Family
5. 8th Generation Intel® Core™ Processor Family
|06_A5H||2, 3, 5||1. Comet Lake H
2. Comet Lake-S
|1, 2. 10th Generation Intel® Core™ Processor Family
1, 2. Intel® Xeon® W processor family
|06_A6H||<=1||Comet Lake U62||10th Generation Intel® Core™ Processor Family
Intel® Xeon® W processor family
|06_A7H||1||Rocket Lake||11th Generation Intel® Core™ Processor Family
Intel® Xeon® E-2300 processor family
|06_A8H||1||Rocket Lake||Intel® Xeon® W-1300 Processor Family|
- Note, 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.
Intel Core processors based on microarchitectures prior to Skylake and Intel Atom processors do not exhibit MCDT behavior but may not enumerate MCDT_NO.
|Processor||Stepping (All unless otherwise noted)||Code Name (s) / Microarchitecture(s)||Product Family|
|06_3FH||2||Haswell Server EP, EP4S||Intel® Xeon® E processor family|
|06_3FH||4||Elkhart Lake (Tremont)||Intel® Xeon® E processor family|
|06_4CH||Cherryview (Airmont)||Intel® Atom® Processor X Series|
|06_4FH||Broadwell Server E, EP, EP4S, EX||Intel® Xeon® E processor family|
|06_56H||3||Broadwell DE V2,V3||Intel® Xeon® D processor family|
|06_56H||4||Broadwell DE Y0||Intel® Xeon® D processor family|
|06_56H||5||Broadwell DE A1, Hewitt Lake (Broadwell DE)||Intel® Xeon® D processor family|
|06_5AH||Anniedale (Airmont)||Intel® Atom® Processors|
|06_5CH||9||1. Apollo Lake (Goldmont - no SGX)
2. Apollo Lake
3. Apollo Lake
|1. Intel® Pentium® Processor J Series
Intel® Pentium® Processor N Series
2. Intel® Celeron® Processor J Series,
Intel® Celeron® Processor N Series
3. Intel® Atom® Processor A Series
|06_5CH||A||Apollo Lake||Intel® Atom® Processor E3900 Series|
|06_5FH||1||Denverton (Goldmont)||Intel® Atom® C processor family|
|06_65H||XMM7272 (Airmont)||Intel® Atom® Processors|
|06_6EH||Cougar Mountain (Airmont)||
Intel® Puma™ 7 Family
|06_75H||Butter (Airmont)||Intel® Atom® Processors|
Intel® Pentium® Processor Silver Series
Intel® Celeron® Processor J SeriesIntel® Celeron® Processor N Series
|06_86H||4||Snowridge (Tremont)||Intel® Atom® Processors|
|06_86H||5 (B step)||Snowridge (Tremont)||Intel® Xeon® D processor family|
|06_86H||7 (C step)||Snowridge (Tremont)||Intel® Xeon® D processor family|
|06_8AH||1||Lakefield B-step (Tremont)||Intel® Core™ Processors with Intel® Hybrid Technology|
|06_8AH||1||Lakefield B-step (Sunnycove)||Intel® Core™ Processors with Intel® Hybrid Technology|
|06_96H||1||Elkhart Lake (Tremont)||Intel® Atom® Processors|
|06_9CH||0||Jasper Lake (Tremont)||Intel® Atom® Processors|
- Refer to Running Average Power Limit Energy Reporting.
- MCDT_NO is CPUID.(EAX=7H,ECX=2):EDX.
Product and Performance Information
Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.