Merge BoringSSL through 9b8b483276da2b3d36ea21e97743e310314a8de0 #2268
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We've historically settled on treating asserts as not in scope for our constant-time goals. Production binaries are expected to be optimized builds, with debug assertions turned off. (We have a handful of assertions in perf-sensitive code that you definitely do not want to run with.) Secret data has invariants too, so it is useful to be able to write debug assertions on them. However, combined with our default CMake build being a debug build, this seems to cause some confusion with researchers sometimes. Also, if we ever get language-level constant-time support, we would need to resolve this mismatch anyway. (I assume any language support would put enough into the type system to force us to declassify any intentional branches on secret-by-data-flow bools, notably those we assert on.) So I'm inclined to just make our asserts constant-time. There are two issues around asserts, at least with our valgrind-based validation: The first is that a couple of asserts over secret data compute their condition leakily. We can just fix these. The only such ones I found were in bn_reduce_once and bn_gcd_consttime. The second is that almost every assert over secret data will be flagged as an invalid branch by valgrind. However, presuming the condition itself was computed in constant time, this branch is actually safe. If we were willing to abort the process when false, the assert is clearly publicly true. We just need to declassify the boolean to assert on it. assert(constant_time_declassify_int(expr)) is really long, so I made an internal wrapper macro declassify_assert(expr). Not sure if that's the best name. constant_time_declassify_assert(expr) is kinda long. constant_time_assert(expr) fits with the rest of that namespace, but reads as if we're somehow running an assert without branching, when the whole point is that we *are* branching and need to explicitly say it's okay to. Fixed: 339 Change-Id: Ie33b99bf9a269b11d2c48d246cc4934be7e239ff Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65467 Reviewed-by: Bob Beck <[email protected]> Commit-Queue: David Benjamin <[email protected]>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2268 +/- ##
==========================================
- Coverage 96.81% 96.74% -0.07%
==========================================
Files 169 169
Lines 20823 20837 +14
Branches 496 496
==========================================
Hits 20159 20159
- Misses 558 571 +13
- Partials 106 107 +1 ☔ View full report in Codecov by Sentry. |
briansmith
force-pushed
the
b/boringssl-merge-2-4
branch
from
36671d5 to
c48119f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.