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

@miss-islington

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>

@bedevere-bot mentioned this pull request

Dec 14, 2020

@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)