-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crypto: set Data Independent Timing flag on arm64 #49702
Comments
DIT is introduced since arm v8.4, are there any considerations for the safety of versions before 8.4?
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. |
@FiloSottile @golang/security This is in the 1.18 milestone; time to move to 1.19? Thanks. |
Linux is discussing how to handle this and the new Intel equivalent. https://lore.kernel.org/lkml/Ywzr2d52ixYXUDWR@zx2c4.com/T/#mfcba14511c69461bd8921fef758baae120d090dc |
https://developer.arm.com/documentation/ka005181/latest
|
Change https://go.dev/cl/598336 mentions this issue: |
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.
The text was updated successfully, but these errors were encountered: