commit | 772a5bed7d5065b301c3979c325248689d36b92c | [log] [tgz] |
---|---|---|
author | Adam Langley <agl@google.com> | Thu Feb 02 14:07:24 2017 -0800 |
committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Thu Feb 02 22:47:05 2017 +0000 |
tree | d33bbc19a461c82bb4e0a3c05151fd9b97114f99 | |
parent | 8671c47bd80a890116cbc760397a616eb2126388 [diff] |
Reorder the X25519 ladderstep stack frame on x86-64. The current X25519 assembly has a 352-byte stack frame and saves the regsiters at the bottom. This means that the CFI information cannot be represented in the “compact” form that MacOS seems to want to use (see linked bug). The stack frame looked like: 360 CFA 352 return address ⋮ 56 (296 bytes of scratch space) 48 saved RBP 40 saved RBX 32 saved R15 24 saved R14 16 saved R13 8 saved R12 0 (hole left from 3f38d80b dropping the superfluous saving of R11) Now it looks like: 352 CFA 344 return address 336 saved RBP 328 saved RBX 320 saved R15 312 saved R14 304 saved R13 296 saved R12 ⋮ 0 (296 bytes of scratch space) The bulk of the changes involve subtracting 56 from all the offsets to RSP when working in the scratch space. This was done in Vim with: '<,'>s/\([1-9][0-9]*\)(%rsp)/\=submatch(1)-56."(%rsp)"/ BUG=176 Change-Id: I022830e8f896fe2d877015fa3ecfa1d073207679 Reviewed-on: https://boringssl-review.googlesource.com/13580 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
There are other files in this directory which might be helpful: