crypto: use subtle.WithDataIndependentTiming for all constant-time APIs

[FiloSottile]

Someone pointed me to this terrifying piece of arm64 documentation.

https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Registers/DIT--Data-Independent-Timing

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.

[erifan]

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.

[ianlancetaylor]

@FiloSottile @golang/security This is in the 1.18 milestone; time to move to 1.19? Thanks.

[FiloSottile]

Linux is discussing how to handle this and the new Intel equivalent. https://lore.kernel.org/lkml/Ywzr2d52ixYXUDWR@zx2c4.com/T/#mfcba14511c69461bd8921fef758baae120d090dc

[AGSaidi]

https://developer.arm.com/documentation/ka005181/latest

The intention of FEAT_DIT is to provide an architectural guarantee that an architecturally defined set of data processioning instructions would be data value timing invariant.

Arm is not aware of any Arm processor implementations from before the introduction of FEAT_DIT that exhibit data value timing variation for the instructions covered by FEAT_DIT, but this behavior was not required by the architecture.

...
Some Arm processor implementations which implement FEAT_DIT (such as the Neoverse-V1) do not exhibit data value timing variation for the instructions covered by FEAT_DIT, irrespective of the PSTATE.DIT setting. This being said, Arm strongly recommends that software transitions to adopting the correct usage of the architectural feature.