On Fri, 13 Aug 2010, Darryl Miles wrote:
>
> While it is possible to make a Valgrind clean (as in memory leaks) executable,
> that loads OpenSSL DSO/DLLs exactly once during the executable lifetime.
>
> I'm not sure it has ever been a feasible goal to make OpenSSL DSO/DLLs able to
> be unloaded (with the aim of subsequently loading). Let alone a goal that
> this
> function of dynamic-linking is claimed to be supported by OpenSSL in its
> documentation.
hi Darryl, the problem is that shared modules are loaded and
unloaded (PAM, PKCS#11 to name two of existing frameworks that work
dynamically with shared modules) and SSL is used more and more often.
So, libssl can be just linked against such modules, ending up being
loaded and unloaded as a side effect. That's why we hit it just
recently, a new provider in the Solaris Crypto Frameowork uses libssl.
As said in my first email, I believe this problem will become more and
more frequent in the future.
> I won't dispute it is a worthy goal of any DSO to be compliant with use of
> dlunload() but I see wider issues needing resolution at the same time. For a
> start doesn't there need to be a mechanism where a superior-executable can ask
> the DSO if it is ready to unload, maybe there are hooks in dlunload() to
> inquire on this.
dlopen/dlclose are part of the UNIX spec and there is nothing
like that. It could be fixed by having a function that unloads just SSL
strings and put it into the .fini section of the shared object (or even
libssl). Unfortunately, such function does not exist in libcrypto, there
is just one generic ERR_free_strings() that unloads all the strings
aside from those in SSL, including those that might be still used by
libcrypto consumers.
> This ignores the nice to have features of:
> * Exposed reference counters for dlopen to the DSO itself
> * Ability for a DSO to say, you can never unload me
the latter was mentioned in my 1st email as a linker option in
Solaris (and it may be a Solaris only thing) but that's still just a
workaround. There is nothing like that in the dlopen/dlclose API.
> Maybe these problem are already solved on the platforms you are working with
> (FreeBSD / OpenSolaris) and I'd certainly like to hear about that. As
> glibc/linux takes a somewhat different stance.
I'm not sure what stance you mean here? The problem can be
reproduced on Linux as well.
thanks, Jan.
--
Jan Pechanec
http://blogs.sun.com/janp
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
