| commit | b74ac2be734c59f59a6f0a7930487bb7b0e4bc26 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Fri Dec 19 13:55:20 2025 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Dec 22 09:35:44 2025 -0800 |
| tree | 2d7127a21e73b7a2741a250d7d3363bbfa657eea | |
| parent | fcc7c8351c50fd05088591ea55d47a44e656a3c4 [diff] |
inject_hash: Support finding the marker symbols in .symtab or .dynsym When testing I2f1999679b1987664da4350d86ac149e52d44303, I found that some build configuration that injected -Wl,--strip-all into the build in some way that I could not figure out how to undo. That meant that the sample shared object lost its marker symbols for where to compute the hash. To work around that, update inject_hash to also check dynamic symbols for the markers. For the markers to end up in there when built via delocate, they must be .globl. However, if we then made them visible[*], we risk polluting the dynamic symbol table of the final binary, because we don't know whether the consumer controlled symbol visibility pre-link with -fvisibility=hidden or post-link (e.g. with a symbol version script). To account for this, they're marked hidden, which actually keeps them out of the dynamic symbol table anyway. But it allows objcopy --set-symbol-visibility to catch and upgrade them in the sample shared library, in builds where an errant -Wl,--strip-all impedes us. (Builds without this problem don't need to both, because the symbol will end up in .symtab.) That, in turn, requires us to stop treating these symbols as synthesized local symbols, so we get a little extra complexity there. [*] To be visible, they actually need to be protected visibility rather than default visibility. Otherwise the assembler complains that we aren't GOT-indirecting all accesses to them. Change-Id: Ia677ac274fc3e55a2e3cc7832f6abae78cc9589b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/86088 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
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.
Project links:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: