Just to summarize and "finish" this: It is definitely not an uclibc bug,
as I said I wrongly assumed that any executable can be dloaded. However
the described behavior by openssl should only apply if compiled as
dynamic lib, but not as a static one. A flag for this was added in
1.1.1b. However node.js did not use the flag yet, which I fixed with a
patch.
Am 03.06.19 um 17:40 schrieb Yann Sionneau:
And just out of curiosity, are you sure that you are following all
requirements described there:
https://github.com/openssl/openssl/blob/df1f538f28c10f2954757164b17781040d2355ef/doc/man3/OPENSSL_init_crypto.pod
?
Especially the "NOTES" part?
On 6/3/19 5:34 PM, Yann Sionneau wrote:
For the record here are what I think are the corresponding threads:
https://github.com/openssl/openssl/issues/654
https://github.com/curl/curl/issues/1055
It seems those thread end up pointing that OpenSSL have invalid
assumptions on atexit() in their code at least for Windows platform.
(for the 2nd link)
This also seems to be of interest
https://github.com/openssl/openssl/issues/653
In any case, I think it is hard to dig deeper in this topic without
looking at the actual code and having more precise information about
what is linked with what, and how (static? dynamic ?).
And see some crash dumps (stack trace).
On 6/3/19 5:16 PM, Luca Lindhorst wrote:
I meanwhile found the problem, it is already known, and they did
something about in the newest OpenSSL version. OpenSSL wants for be
sure, that their cleanup routines on atexit are executed. However if
it was loaded by dload and later closed by dlclose neccessary code
is not available anymore on exit. To achieve this they do a
(presumably second) dload on their library to keep it loaded. This
makes no sense if it is dynamically compile time linked, but does
not really harm. But when linked statically like in my case it does
something invalid, which doesn't really hurt either, but on uclibc
apparently leads to a printed error message.
This might actually be a thing to consider for uclibc, not printing
out an error, and only rely on the "normal" error handling
mechanisms, like in this case dload returning NULL.
Am 03.06.19 um 17:06 schrieb Rich Felker:
On Mon, Jun 03, 2019 at 03:47:48PM +0200, Luca Lindhorst wrote:
Thanks for the help.
I guess there isn't a problem then. I didn't know that you can only
load a "special" ET_DYN PIE elf, it makes sense though.
FYI: I am investigating a problem relating NodeJS on ARM. And after
some more investigating I found out that openssl tries to dlload
itself again, for a reason I don't fully understand yet
("|Deliberately leak a reference to ourselves. This will force the
library to remain loaded until the atexit() handler is run at
process exit.|"). But since openssl is statically linked in node, it
loads the binary again.
Therefore this certainly isn't a uclibc problem.
I don't understand why it would dlopen the openssl binary rather than
libssl for this purpose. It should not be doing that, and there's
probably some other bug in openssl or in your integration of it that's
making it do that. It also might be something you could consider a bug
in uclibc -- attempting to dlopen the main program itself, rather than
some other executable, should probably give a handle to the existing
instance, rather than attempting to load it again.
Rich
-- Unsere Aussagen koennen Irrtuemer und Missverstaendnisse enthalten.
Bitte pruefen Sie die Aussagen fuer Ihren Fall, bevor Sie
Entscheidungen auf Grundlage dieser Aussagen treffen.
Wiesemann & Theis GmbH, Porschestr. 12, D-42279 Wuppertal
Geschaeftsfuehrer: Dipl.-Ing. Ruediger Theis
Registergericht: Amtsgericht Wuppertal, HRB 6377 Infos zum
Datenschutz: http://www.wut.de/datenschutz
Tel. +49-202/2680-0, Fax +49-202/2680-265, http://www.wut.de
_______________________________________________
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
-- Unsere Aussagen koennen Irrtuemer und Missverstaendnisse enthalten.
Bitte pruefen Sie die Aussagen fuer Ihren Fall, bevor Sie Entscheidungen
auf Grundlage dieser Aussagen treffen.
Wiesemann & Theis GmbH, Porschestr. 12, D-42279 Wuppertal
Geschaeftsfuehrer: Dipl.-Ing. Ruediger Theis
Registergericht: Amtsgericht Wuppertal, HRB 6377
Infos zum Datenschutz: http://www.wut.de/datenschutz
Tel. +49-202/2680-0, Fax +49-202/2680-265, http://www.wut.de
_______________________________________________
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
