If exploited, these flaws can allow attackers to gain unauthorized access to sensitive information or generally cause problems
Recently the news broke that Eric Biggers one of the developers of the Adiantum cipher and maintainer of the Linux kernel subsystem fscrypt, proposed a set of patches to block that security issues derived from the peculiarity of the Intel processors that do not guarantee execution times constants for the instructions of the different data processed.
Regarding his proposal, he mentions that in Intel processors, the problem has been manifesting itself since the Ice Lake family, in addition to the fact that Also a similar problem is observed in ARM processors.
The execution time dependency of the instructions of the data processed in these instructions is considered by the author of the patchesIt's like a vulnerability in processors, since such behavior cannot guarantee the security of cryptographic operations made in the system.
I would like to draw people's attention to the fact that in the latest Intel and Arm CPUs , by default at the time of execution of the instructions can depend on the data operated values. This even includes instructions like addition, XOR and iAES instructions, which are traditionally assumed to be constant time with respect to the operated data values.
Many implementations of cryptographic algorithms rely on the fact that data does not affect instruction execution time, and violation of this behavior can lead to the creation of side-channel attacks that retrieve data based on time analysis. processing.
Potentially runtime dependency on data can also be used to stage attacks to determine user space kernel data.
Non-constant time instructions break the cryptographic code that is based on the constant time code to prevent time attacks on cryptographic keys, i.e. most
cryptographic code. This problem can also have a broader impact on the ability to
operating systems to protect data from non-privileged processes.For Intel, processors with Ice Lake and later are affected by this issue.
The solution for this problem is to set a CPU flag that restores the old, correct
data independent timing behavior: DIT on Arm and DOITM on Intel.
According to Eric Biggers, including for instructions that perform addition and XOR operations, as well as for specialized AES-NI instructions, no constant runtime provided by default (the information not confirmed by testing, according to other data, there is a delay of one cycle when multiplying vectors and counting bits).
To disable this behavior, Intel and ARM have proposed new solutions, such as the PSTATE DIT (Data Independent Timing) bit for ARM CPUs and the DOITM (Data Operand Independent Timing Mode) MSR bit for Intel CPUs, returning the previous behavior with constant execution time.
Intel and ARM recommend enabling protection as needed for critical code, but in reality, important computations can occur anywhere in the kernel and in user space, so the possibility of permanently enabling kernel-wide DOITM and DIT modes is being considered.
For ARM processors, Linux 6.2 kernel branch already received patches that change the behavior of the kernel, but these patches are considered insufficient since they only cover the kernel code and do not change the behavior of user space.
For Intel processors, the inclusion of the protection is currently only in the review stage. The performance impact of the patch has not yet been measured, but according to Intel documentation, enabling DOITM mode reduces performance (for example, due to disabling some optimizations, such as data-specific preloading) and, in future processor models, performance degradation may increase.
Finally, if you are interested in being able to know more about it, you can consult the details in the following link