It's a flag that ensures that "the timing of every load and store instruction is insensitive to the value of the data being loaded or stored" and "for certain data processing instructions, the instruction takes a time which is independent of: the values of the data supplied in any of its registers".
The nightmare fuel implication is that with this flag unset, instructions like MUL and LOAD might take different time based on the value they operate on. Due to the potential for timing attacks, this is not acceptable in any cryptographic code.
We should probably put a call-and-defer at each public crypto entry point that on arm64 detects the feature and set/unsets the flag. Setting it for the whole program might have an unacceptable performance cost, even if marginal.
I'll think about requesting a freeze exception, depending on the implementation details.
The text was updated successfully, but these errors were encountered:
DIT is introduced since arm v8.4, are there any considerations for the safety of versions before 8.4?
We should probably put a call-and-defer at each public crypto entry point that on arm64 detects the feature and set/unsets the flag.
We may need to consider this situation. The function is preempted before it unsets the flag. Then the goroutine may be switched to run on other m, and other goroutines may also be switched to run on this m. The setting of the flag for different m is inconsistent.