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

[3.6] bpo-40791: Make compare_digest more constant-time. (GH-23438) #23767

Merged
merged 1 commit into from
Dec 14, 2020

Conversation

miss-islington
Copy link
Contributor

@miss-islington miss-islington commented Dec 14, 2020

The existing volatile left/right pointers guarantee that the reads will all occur, but does not guarantee that they will be used. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between result and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre jeanpierreda@google.com
(cherry picked from commit db95802)

Co-authored-by: Miss Islington (bot) 31488909+miss-islington@users.noreply.github.com

https://bugs.python.org/issue40791

Automerge-Triggered-By: GH:tiran

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <jeanpierreda@google.com>
(cherry picked from commit db95802)

Co-authored-by: Miss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
@miss-islington
Copy link
Contributor Author

@miss-islington and @benjaminp: Status check is done, and it's a success ✅ .

@miss-islington
Copy link
Contributor Author

@miss-islington and @benjaminp: Status check is done, and it's a success ✅ .

1 similar comment
@miss-islington
Copy link
Contributor Author

@miss-islington and @benjaminp: Status check is done, and it's a success ✅ .

@miss-islington
Copy link
Contributor Author

@miss-islington and @benjaminp: Status check is done, and it's a success ✅ .

@miss-islington
Copy link
Contributor Author

Sorry, I can't merge this PR. Reason: You're not authorized to push to this branch. Visit https://docs.github.com/articles/about-protected-branches/ for more information..

@ned-deily ned-deily merged commit 8bef9eb into python:3.6 Dec 14, 2020
@miss-islington miss-islington deleted the backport-db95802-3.6 branch December 14, 2020 17:05
rickprice pushed a commit to ActiveState/cpython that referenced this pull request Apr 11, 2024
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <jeanpierreda@google.com>
(cherry picked from commit 8bef9eb)
icanhasmath pushed a commit to ActiveState/cpython that referenced this pull request Jun 26, 2024
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <jeanpierreda@google.com>
(cherry picked from commit 8bef9eb)
rickprice pushed a commit to ActiveState/cpython that referenced this pull request Jun 26, 2024
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <jeanpierreda@google.com>
(cherry picked from commit 8bef9eb)
icanhasmath pushed a commit to ActiveState/cpython that referenced this pull request Jul 30, 2024
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <jeanpierreda@google.com>
(cherry picked from commit 8bef9eb)
icanhasmath pushed a commit to ActiveState/cpython that referenced this pull request Jul 30, 2024
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <jeanpierreda@google.com>
(cherry picked from commit 8bef9eb)
icanhasmath pushed a commit to ActiveState/cpython that referenced this pull request Aug 6, 2024
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <jeanpierreda@google.com>
(cherry picked from commit 8bef9eb)
icanhasmath pushed a commit to ActiveState/cpython that referenced this pull request Aug 7, 2024
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <jeanpierreda@google.com>
(cherry picked from commit 8bef9eb)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-bug An unexpected behavior, bug, or error type-security A security issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants