bssl-compat: Add rand function used by Envoy

[pfl]

Accessing RAND_bytes() from OpenSSL with dlsym() keeps the library in line with C calling conventions. I was trying out C++ namespaces, but that caused the source code and calling conventions become C++, which wasn't what was intended. There is also a minimal "test" program in my branch envoy_rand_dlopen_test should anyone want to print out a string of random bytes.

Currently this links to the first OpenSSL library found, which is the one installed by the system. Some work needed here if OpenSSL is to be downloaded, compiled and linked against.

---

Add RANDbytes() function which is the only function used from the RAND family by Envoy. Find the identically named OpenSSL function with dlsym and store its value for next calls to this function.

Watch out for return values, OpenSSL uses < 0 to indicate errors in version 1.1.1 (and 0 in 3.0) where BoringSSL always uses 0.

Signed-off-by: Patrik Flykt patrik.flykt@intel.com

[twghu]

• Can we add a note to the README.md
• Other functions in the library rely on link time resolution of library rather than call to dlsym, concern here is threading.
• License declarations? Copyright Intel? ASF 2.0 without the full blurb
• The divergence from using !defined(BORINGSSL_NO_CXX)" vs "#if defined(__cplusplus)" ack as preventing C++ name mangling.

[pfl]

If C compatibility is desired, I can't figure out any other way of doing this except with a prefixed wrapper function + preprocessor define. If I use C++ and a namespace, the whole library turns into C++ calling conventions.

[tedjpoole]

@pfl I concur this looks like the only reasonable way to achieve the function interception/wrapping. Also, compared to the dlopen()/dlsym() mechanism, there is no concern with thread safety or indirection overhead, because it's all screwed together at link time rather than run time.

[pfl]

The options so far are:

1. dlsym(), the first approach
2. prefix + preprocessor define as above
3. library symbol mangling, but if openssl is to be updated/changed afterwards, this is not feasible
4. do a C++ only library We have one vote from @tedjpoole for 2., if I read him correctly

[pfl]

As discussed, let's go with dlopen(). The initialization of the dlsym() accessed function pointers are not in the library constructor function specified with attribute ((constructor)). Thus we get needed functions nicely in place when the library is loaded.

[pfl]

Looks like this PR updates submodule envoy also, is it intentional?

That is a bug, will fix.