Skip to content
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

Open
FiloSottile opened this issue Nov 21, 2021 · 1 comment
Open

crypto: set Data Independent Timing flag on arm64 #49702

FiloSottile opened this issue Nov 21, 2021 · 1 comment

Comments

@FiloSottile
Copy link
Contributor

@FiloSottile FiloSottile commented Nov 21, 2021

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
Copy link
Contributor

@erifan erifan commented Nov 22, 2021

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.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants