Data Operand Independent Timing Instruction Set Architecture (ISA) Guidance

This document describes a new feature supported by some recent Intel processors, adding a data operand independent timing mode which can be used to ensure “constant time” execution for a specific subset of instructions. Although not relevant for the majority of code, data operand independent timing (DOIT) is a useful property for code which has specifically been written to execute in constant time such as cryptographic algorithms. This mode allows constant time code to inform the processor that data operand independent timing is needed.

DOIT requires disabling hardware optimizations and/or performance features on some processors; for example, enabling data operand independent timing might disable data-dependent prefetching. This means that the DOIT mode may have a performance impact, and Intel expects the performance impact of this mode may be significantly higher on future processors. 

This functionality is intended for use by software which has already applied other techniques to mitigate software timing side channels, such as those documented in Intel's Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations. Such software is typically limited to cryptographic implementations. This mode is not intended to provide any additional security benefit for software that is not already applying these software techniques. Due to its potential performance impact, Intel does not recommend enabling this mode globally. Instead, the mode should be enabled only for software that is specifically designed to benefit from the additional properties provided by the DOIT mode. In order to allow this mode to be enabled for the subset of an application that is constant time, Intel plans to add new capabilities in future processors to allow applications to dynamically enabled/disabled when system software permits.

The data operand independent timing instructions section provides a list of the instructions that have data-independent timing that can be used in conjunction with the previous guidelines. Software using these instructions for “constant time” code can enable the DOIT mode for 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. 

Instructions with Data Operand Independent Timing (DOIT)

Refer to the list of documented data operand independent timing instructions for a list of instructions with data operand independent timing. 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. Refer to the frequency-throttling side channel guidance for more information. 

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, as discussed in Intel's Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations. 

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

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 that read or write to memory may have different timing depending on mask register values.  

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 measurements¹) 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 developers 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[12] is 1. WRMSR to IA32_UARCH_MISC_CTL (MSR index 1B01H) is not defined as a serializing instruction.  

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.

Software Enabling

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 increase 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.

The existing Intel SGX architecture cannot manipulate DOITM and cannot trust the OS to manipulate DOITM.

To mitigate attacks on constant time code running in enclave mode, processors that enumerate support for DOITM will always enable data operand independent timing mode. This behavior is independent from the setting of DOITM itself.

This design choice considers both the complexity of extending the Intel SGX architecture to allow more dynamic control of mitigations and the existing reduced performance within enclave mode.

Note: Software with similar complexity concerns and which can tolerate reduced performance may also converge on a design that opts to leave DOITM always enabled. 

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. Unlike Intel SGX enclaves, TDs can decide to set this based on their threat model. 

Enumeration and Architectural MSRs

DOIT Enumeration

IA32_ARCH_CAPABILITIES[12] 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. 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 with MXCSR Configuration Dependent Timing. For additional information on MXCSR configuration, refer to MXCSR Configuration Dependent Timing.

IA32_UARCH_MISC_CTL MSR Definition 

This MSR is logical processor scoped and has a reset value of 0.

Documented Data Operand Independent Timing Instructions

Refer to the list of documented Data Operand Independent Timing instructions.

Footnotes

1. Refer to Running Average Power Limit Energy Reporting.
2. MCDT_NO is CPUID.(EAX=7H,ECX=2):EDX[5].