Community
Participate
Working Groups
Compiling an application with both TinyDTLS and OpenSSL results in compile-time and/or link-time symbol conflicts. Steps to reproduce: For example, if "#include <openssl/ssl.h>" is added to the dtls-client.c test program, and "-lssl" is added to the link parameters, the following build errors occur (on Ubuntu 14.04 LTS with OpenSSL installed): <pre> cc -Wall -g -O2 -I.. -DDTLSv12 -DWITH_SHA256 -L.. dtls-client.c -ltinydtls -lssl -o dtls-client In file included from ../hmac.h:28:0, from ../state.h:30, from ../dtls.h:29, from dtls-client.c:22: ../sha2/sha2.h:114:3: error: conflicting types for ‘SHA256_CTX’ } SHA256_CTX; ^ In file included from /usr/include/openssl/x509.h:107:0, from /usr/include/openssl/ssl.h:156, from dtls-client.c:18: /usr/include/openssl/sha.h:142:4: note: previous declaration of ‘SHA256_CTX’ was here } SHA256_CTX; ^ </pre> And this is repeated for the symbols SHA512_CTX, SHA256_Init(), SHA256_Update(), and SHA256_Final(). If the header files are included in different object files, the conflict happens at link time instead of compile time. We considered prefixing all the symbols with "DTLS_". But I would imagine this would create other issues. So we're looking for guidance on this. Apologies in advance if this has already been discussed/addressed.
Created attachment 260594 [details] Patch that adds "DTLS_" to global-scoped preprocessor defs/symbols
I should add that the patch content comes courtesy of Kyungsun Cho @ Samsung - adding to the cc list.
You have a valid issue here but the solution is not that simple because the sha2 code is imported from an external source. Changing this code would require opening the respective CQ again. Thus, I could imagine several possible solutions, (sorted by ascending pain level): 1. Avoid including tinydtls headers and openssl headers in the same C module. This could be done, e.g., by another level of indirection. 2. Hide the definition of SHA256_CTX from the tinydtls public API. This could be done, e.g., by another level of indirection. 3. Use the prefix solution as proposed, accompanied by another CQ. Please submit any associated patches to the gerrit review system, containing a proper Signed-Off-By: header, Change-Id:, and a reference to this bug.
I believe (1) doesn't solve the problem, unfortunately. The code will compile, but the symbols for SHA256_Init, SHA256_Update, SHA256_Transform, and SHA256_Final are defined in both libraries. So an exe trying to use TinyDTLS can get linked against the OpenSSL versions of these functions - causing badness (which is what I believe Samsung is experiencing - in the form of an access violation). I'm sorta thinking (2) is the best option. But trying to figure out. To keep the above functions out of the symbol table, I think they'd have to be declared static - which would mean the redirection functions would need to be in the same source file, correct? If so, this would seem to defeat the purpose - since the code would need to be modified. But I'm probably missing some kind of build-level technique that could prevent this (at least I hope I am...).
Dear Mr. Craig, thank you for your inviting me. And dear Mr. Olaf, nice to meet you. This is Kyungsun from Samsung. As your saying, I will commit my |tiyndtls-sha| symbol renaming codes and please review the uploaded codes only for reference. I understand well your saying and the situation for this issue, and I think also, it is not best solution, |tinydtls-sha| symbol renaming. In addition, this codes were checked and verified on our commercialized products. Thank you for your services.
Craig, I completely agree with your observations. As a matter of fact, I have been playing with option (2) some time ago for testing a different SHA256 implementation. So maybe, that's the proper way forward. Regarding the issues at link time, I would like to point out that the reason here is code duplication which is a bad thing per se, especially in the constrained space. I wonder if we can come up with a build mechanism that allows for using only one version of the code. This could enable. e.g., hardware-based implementation of cryptographic functions such as SHA256, AES128 etc.
I just found that sha2.c has modifications against the original version to integrate the code with tinydtls.[1] Therefore, the pain of adjusting imported code is already there. This makes option (3) a possible and quick way forward. Cho, Would you please submit your patch to Gerrit[2] into refs/for/master? [1] http://dev.eclipse.org/ipzilla/show_bug.cgi?id=10515 [2] https://git.eclipse.org/r/p/tinydtls/org.eclipse.tinydtls
Dear all, I'm ready for committing the codes. And as Mr. Olaf said, the renaming code change is a little bit. Now security approval for corporate network firewall is in progress. Sorry and please wait a little, thank you.
New Gerrit change created: https://git.eclipse.org/r/69697
Dear all, the renaming change was committed on |tinydtls/org.eclipse.tinydtls|. - https://git.eclipse.org/r/#/c/69697/ Sorry for my late commit and please review this, thank you.
Gerrit change https://git.eclipse.org/r/69697 was merged to [master]. Commit: http://git.eclipse.org/c/tinydtls/org.eclipse.tinydtls.git/commit/?id=1ddeffa2a924716d85861be6ffb962a8877e2a69
