Fix GOTPCREL accesses to symbols defined outside the module.

5c38c05b2657739daea2ca01a93900e30ee3764f caused foo@GOTPCREL for
external foo to resolve to bcm_redirector_foo. This is morally
equivalent to using foo@PLT when a pointer to foo is needed. But this
does not work if foo is data. Notably, this ended up mangling
OPENSSL_ia32cap_P because it failed to recognize it as an symbol in the
library (but external to the module). It also mangles some things that
ASan emits.

(It also breaks non-NULL function pointer comparisons, but those are
silly.)

Instead, apply a variation of the OPENSSL_ia32cap_addr_delta trick that
works for the GOT. "addr_delta" is really weird, so I'm calling this an
"external relocation". This causes fprintf(stderr) to work and also
seems to keep ASan compiling. I was unable to reproduce the case that
5c38c05b2657739daea2ca01a93900e30ee3764f added the bcm_redirector_foo
transform for.

Also tighten up the pattern. No need to reference a bit of memory twice
since we just loaded it into a register.

Change-Id: If5520fc0887e83e23a08828e40fbbed9e47d912e
Reviewed-on: https://boringssl-review.googlesource.com/16345
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
1 file changed
tree: 7bae861b2ea0920d87671be4520076f46357e0b8
  1. .github/
  2. crypto/
  3. decrepit/
  4. fipsoracle/
  5. fuzz/
  6. include/
  7. infra/
  8. ssl/
  9. third_party/
  10. tool/
  11. util/
  12. .clang-format
  13. .gitignore
  14. API-CONVENTIONS.md
  15. BUILDING.md
  16. CMakeLists.txt
  17. codereview.settings
  18. CONTRIBUTING.md
  19. FUZZING.md
  20. INCORPORATING.md
  21. LICENSE
  22. PORTING.md
  23. README.md
  24. STYLE.md
README.md

BoringSSL

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: