OPENSSL calls from java
Hi I am currently working on calling crypto library from Java program. Since the algorithms are already available in OpenSSL i presume i need to make calls to the necessary methods. Does anyone have an example of Java programs calling the Openssl libraries ? Thanks Sandesh -- View this message in context: http://www.nabble.com/OPENSSL-calls-from-java-tp15045566p15045566.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Static global - bug? (Re: Two valgrind warnings in OpenSSL -possible bug???)
On Mon, Jan 21, 2008 at 05:34:43PM -0800, David Schwartz wrote: > > - there is no difference between > > multithreaded and non-multithreaded _compilation_ (surely not for errno > > and malloc). > > Really? So 'errno' refers to a process global in both cases?! (Note that I > said the "definition", not the implementation.) If your glibc (only) supports NPTL, which is the case for recent versions, errno is defined like this: # define errno (*__errno_location ()) errno is stored in Thread Local Storage (TLS). You can't link to the global errno anymore. Using "extern int errno" will actually result in a linking error: /usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section .tbss mismatches non-TLS reference Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Static global - bug? (Re: Two valgrind warnings in OpenSSL-possible bug???)
> errno is stored in Thread Local Storage (TLS). You can't link to the > global errno anymore. For a single-threaded process, there is no distinction between thread-local storage and a global variable. For a multi-threaded process, there is. The same code can have a different semantic meaning depending upon whether the process is single-threaded or multi-threaded. > Using "extern int errno" will actually result in a linking error: > /usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section > .tbss mismatches non-TLS reference My point was simply that there is a difference between single-threaded and multi-threaded compilation. In one case, 'errno' refers to a variable that is process global (since there is only one thread). In the other case, it does not. That these two different semantics are implemented by the same code doesn't change the fact that the semantics are different. In fact, it makes the important point that the semantics of code can be changed by whether the process is single-threaded or multi-threaded. On many Linux distributions, it is perfectly acceptable to do the following: #ifdef _REENTRANT // inefficient thread-safe code #else // more efficient code that assumes 'errno' is process-global #endif This is because many distributions only guarantee POSIX compliance if you specify '-pthread' and '-pthread' always defines _REENTRANT. You have to follow the rules if you want the platform to follow the rules. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Static global - bug? (Re: Two valgrind warnings in OpenSSL -possible bug???)
Tomas Mraz, 2008-01-24: > So IMO what Paul Sheer is doing - disabling all locking in OpenSSL given > that there won't be any static and/or global variables in the OpenSSL > code called is 100% safe thing if the threads do not share any data > manipulated within the OpenSSL library. As mentioned in the docs, multithreaded OpenSSL needs special application support, period. Not providing this means you'll get undefined/undesirable results. Old MySQL versios did try this approach (i.e. using the library in an undocumented way). Perhaps it sort-of worked for them while they developed the SSL support for the database engine, but newer MySQL/OpenSSL combinations didn't work at all (for example, MySQL-4.0.23a+OpenSSL-0.9.7c). They fixed it, albeit a few years down the road. Separately, I'd suggest a different development approach: first, implement OpenSSL locking support. Do some measurements, with and without locking. I'd be interested to get some quantitative evidence before proceeding with this thread. Leandro __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Static global - bug? (Re: Two valgrind warnings in OpenSSL-possible bug???)
On Mon, Jan 28, 2008 at 02:22:09PM -0800, David Schwartz wrote: > > > errno is stored in Thread Local Storage (TLS). You can't link to the > > global errno anymore. > > For a single-threaded process, there is no distinction between thread-local > storage and a global variable. For a multi-threaded process, there is. There is no "global" variable named errno, it only exist in the TLS. You could say that because there is only 1 TLS, that it's global, and it acts that way. But it's not really the same as a normal global variable. You can't access the variables in the same manner you access other global variables. > The same code can have a different semantic meaning depending upon whether > the process is single-threaded or multi-threaded. > > > Using "extern int errno" will actually result in a linking error: > > /usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section > > .tbss mismatches non-TLS reference > > My point was simply that there is a difference between single-threaded and > multi-threaded compilation. In one case, 'errno' refers to a variable that > is process global (since there is only one thread). In the other case, it > does not. In case of errno on a glibc system with NPTL there is no difference in the compiled code. You always get the same function call. Let's assume for a moment that openssl is not "compiled for multi thread", whatever you mean with that exactly. Even when the application is using threads, when openssl tries to use errno it will get the one for the current thread. > That these two different semantics are implemented by the same code doesn't > change the fact that the semantics are different. In fact, it makes the > important point that the semantics of code can be changed by whether the > process is single-threaded or multi-threaded. I'm not at all saying that the semantics are the same. All I'm saying is that in case of errno on a recent glibc there is no difference in the compiled code depending on wether your application or library is multi-threaded or not. > On many Linux distributions, it is perfectly acceptable to do the following: > > #ifdef _REENTRANT > // inefficient thread-safe code > #else > // more efficient code that assumes 'errno' is process-global > #endif On many Linux distributions it's required that if such code is in a library that it's compiled using -D_REENTRANT for the packages they ship. With other words, if the library can be compiled reentrant, that's what we want. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Static global - bug? (Re: Two valgrind warnings in OpenSSL -possible bug???)
Let's say you have 1600 clients. Let's say that you have 40 threads, and each thread handles 40 connections. Now let's say that each thread initializes it's own SSL_CTX structure. The SSL_CTX structure contains most of the data required for SSL functionality. Because each SSL_CTX structure has one-and-only-one thread accessing it, there can be no contention within the SSL_CTX structure's data. The next question is "is there any OTHER data (i.e. global data) within the OpenSSL library that the threads may be accessing concurrently?". The answer is "YES there are a few of these." Now of this global data, there is that which is initialized once on startup, and thereafter is "read-only", and there is that which is constantly updated. The former data is not of concern. My investigation reveals that the instances of global shared data that are modified after startup are very few. These are handled in the list in my previous emails. Of what VALUE this is, is questionable, because, it has been pointed out that locking with such an application would have minimal overhead. Myself I LIKE the idea of my code crashing so I do EVERYTHING I can to encourage my programs to crash. Each program crash is an indication of my not understanding something about my program!! :-) Saying there "MAY be something dangerous about what I am doing" is a reason TO do it because, within that "MAY" is something I don't understand about the OpenSSL library. And I don't like working with libraries that I don't understand! :^) Further, on some systems you can't link with libpthread if you intend to use fork(). I have two builds of my software, one that does fork()ing and one that does pthread_create()ing. So I am trying to avoid having to have two installations of OpenSSL on every build platform. -paul On Jan 25, 2008 4:45 PM, Leandro Santi <[EMAIL PROTECTED]> wrote: > Tomas Mraz, 2008-01-24: > > So IMO what Paul Sheer is doing - disabling all locking in OpenSSL given > > that there won't be any static and/or global variables in the OpenSSL > > code called is 100% safe thing if the threads do not share any data > > manipulated within the OpenSSL library. > > As mentioned in the docs, multithreaded OpenSSL needs special > application support, period. Not providing this means you'll > get undefined/undesirable results. > > Old MySQL versios did try this approach (i.e. using the library > in an undocumented way). Perhaps it sort-of worked for them > while they developed the SSL support for the database engine, > but newer MySQL/OpenSSL combinations didn't work at all (for > example, MySQL-4.0.23a+OpenSSL-0.9.7c). They fixed it, albeit a > few years down the road. > > Separately, I'd suggest a different development approach: first, > implement OpenSSL locking support. Do some measurements, with > and without locking. I'd be interested to get some quantitative > evidence before proceeding with this thread. > > Leandro > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] >
