[3.7] bpo-40791: Make compare_digest more constant-time. (GH-20444) by miss-islington · Pull Request #23438 · python/cpython

@ssbr @miss-islington

* bpo-40791: Make compare_digest more constant-time.

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>

benjaminp

gentoo-bot pushed a commit to gentoo/cpython that referenced this pull request

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>

Rebased for Python 2.7 by Michał Górny <mgorny@gentoo.org>

miss-islington added a commit to miss-islington/cpython that referenced this pull request

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>

ned-deily pushed a commit that referenced this pull request

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>

@ssbr ssbr mannequin mentioned this pull request

Aug 24, 2023

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)