[openssl-users] Double free of session occurs in multithread program.
Hello, I am using OpenSSL's API to create multithreaded programs. Check the contents of the program in ssl_test.c. I have the following two questions. The purpose of the question is to create a program that does not cause double free. Question 1. Is this program correct as a program without double free? Question 2. Because this program is complicated, I want to make it a simple program. I want to easily create a program that does not cause double free. If you can create with this OpenSSL API different from this program, please tell us about API and usage. I will explain this program. It takes time to create a session each time communicate. Therefore, this program reuses sessions. If it set the references of the SSL_SESSION structure to 1 or higher, the session will not be released. SSL_connect() creates a new session. At this time, references are incremented with SSL_get1_session(). This will cause references to be greater than 1, so the session will not be freed. Multiple threads will share this session on subsequent communications. When the session expires, it is necessary to release the old session that was being reused. SSL_SESSION_free() can free old sessions that were being reused. When executing SSL_SESSION_free(), specify the address of the session(SSL_SESSION structure). This program outputs a core dump when deleting the line of "/*add*/" in ssl_test.c. The cause is to double free the address of the same session by two threads. As a measure against this problem, I limit the old session to one release. Therefore, flag (fs_isDelete) is set to 1 when the preceding thread releases the old session. After that, the following thread does not release the old session because the flag (fs_isDelete) is 1. I will explain the API that affects the references of the SSL_SESSION structure. (1) SSL_set_session() Create a session to reuse. I will explain the references. The references of the reusing session are incremented. (2) SSL_connect() If the session has not expired, we will use the session to reuse. If the session has expired, we will create a new session. I will explain the references. If the session has not expired, references will not change. If the session has expired, the references for the new session are 1. If the session has expired, the references of the old session will be decremented. (3) SSL_get1_session() If the session has not expired, obtain the address of the session to reuse. If the session has expired, we will get a new session. I will explain the references. If the session has not expired, the references of the session to be reused will increment. If the session has expired, the references of the new session will increment. (4) SSL_SESSION_free() SSL_SESSION_free() can free old sessions that were being reused. When executing SSL_SESSION_free(), specify the address of the session (SSL_SESSION structure). I will explain the references. The references of the old session are decremented. If references is 0, old sessions are freed. If references are already 0, double the address of the same session. I will explain the sequence of double free. I will explain the operation in single thread. First, thread 0 creates a new session. Thread 0 References for sessions to reuse SSL processing starts. SSL_connect() -> (+1) (1) SSL_get1_session() > (+1) (2) SSL_free() > (-1) (1) SSL processing is terminated. After that, thread 1 reuses the session. At this time, the session may expire. In that case, SSL_SESSION_free() decrements the references of the old session. Thread 1 References of old sessions that have expired SSL processing starts. SSL_set_session() -> (+1) (2) SSL_connect() -> (-1) (1) SSL_SESSION_free() > (-1) (0) SSL processing is terminated. I will explain the operation in multithreading. Thread 1, SSL_SESSION_free() decrements references for old sessions. After that, thread 2 also decrements the references of the same session and double-releases it. Thread 1 Thread 2 SSL processing starts. SSL processing starts. References of old sessions that have expired SSL_set_session() -> (+1) (2) (+1) (3) <- SSL_set_session() SSL_connect() -> (-1) (2) (-1) (1) <- SSL_connect() SSL_SESSION_free() > (-1) (0) (-1) (-1) < SSL_SESSION_free() SSL processing is terminated. Doubles the address of the same session. ssl_test.c --- #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define MAX_SOCKET_COUNT 2 #define SOCKID_EMPTY 0 int localSocket[MAX_SOCKET_COUNT]; int currentSocketCount = 0; char *g_premorthostname = "hoge"; char *g_pserver_port_no = "12345"; #define CERTIFICATEFILEPATH
Re: [openssl-users] Build OpenSSL on SUSE Linux Enterprise Server for z Systems
Hello All.
Sorry for the late reply.
I understood.
Thank you very much.
Best regards,
and I'll try that.
Manabu
> On May 12, 2017, at 5:00 PM, Michael Wojcik <michael.woj...@microfocus.com>
> wrote:
>
> >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> >> Behalf Of Thomas Francis, Jr.
> >> Sent: Friday, May 12, 2017 15:55
> >>
> >>> On 5/10/17 3:55 AM, 共通基盤ＳＳＬ［業務ＩＤ］ / COMMONSSL，GYOUMU
> wrote:
> >>>
> >>> I will build OpenSSL on SUSE Linux Enterprise Server for z Systems.
> >
> > What version of OpenSSL?
> >
> >>> But, there is not yet the machine for build, so I cannot do actual
> >>> machine verification.
> >>>
> >>> The CPU is not Intel architecture, is probably z/Architecture.
> >
> > Yes, Linux for System z runs on z-architecture CPUs.
> >
> >>> I want to know beforehand the appropriate command-line parameters
> >>> for executing "Configure".
> >>>
> >>> Is it right to specify "linux64-s390x" as follows?
> >>>
> >>> (1)cd //openssl-1.0.2k
> >>>
> >>> (2)./Configure linux64-s390x
> >>
> >> I'd suggest just running "./config". That will pick the appropriate
> >> 64-bit target. Only use Configure if you want to do something
> >> non-standard. :)
> >
> > That's certainly the place to start. Whether it will work is another
> question.
> >
> > When we build OpenSSL for z Linux (RHEL and SLES), we use a modified
> Configure that:
> >
> > * Adds -fPIC and -mbackchain. This is because we compile OpenSSL into
> an archive library that is then linked into a shared object, so we have
> to force on the shared-object flags in Configure.
> >
> > * Replaces -O3 with -O1, preferring robustness (or, if you prefer,
> toleration for sloppiness and error) and ease of problem determination over
> performance.
> >
> > * Replaces the asm setting[1] with ${no_asm}, for the same reason.
> >
> > * For 32-bit, removes /highgprs. According to my notes, highgprs does
> not work correctly with some glibc versions on zLinux.
> >
> > The OP probably doesn't need the first three and may well not need the
> last. Depending on how clever one gets with building and using OpenSSL,
> though, config+Configure aren't always sufficient as supplied. That's not
> a criticism - trying to accommodate every use case is not a good use of
> the OpenSSL development team's time.
> >
> > But unless you're happy with the default build parameters and comfortable
> with your platform, be prepared to learn how the OpenSSL build works.
>
> I think in general, the same caveat applies for any system. The default
> build settings might not be what you want. But in most cases (including
> Linux for z), they will get you libraries that'll work with the system
> compiler toolchain if you pass only the minimum flags to specify where the
> headers and libraries can be found.
>
> I figure if you need something else you probably already know that, and
> can pass the appropriate flags in CFLAGS, CPPFLAGS, or LDFLAGS. :) Or create
> a custom target.
>
> TOM
>
> PS Regarding highgprs; I suspect that's actually a problem of mixing 32-bit
> s390x binaries with s390 binaries. There is a difference. But old bugs
> and miscommunication means that sometimes the s390 system will think it
> can load an s390x binary (and sometimes think it succeeded). :)
>
> > [1] There are two zLinux targets in the 1.0.2 Configure, for 64- and 32-bit.
> The linux64-s390x target uses ${s390x_asm} for its asm section, but the
> linux32-s90x uses an eval expression that edits $s390x_asm. We disable asm
> for both.
> >
> >
> > Michael Wojcik
> > Distinguished Engineer, Micro Focus
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Build OpenSSL on SUSE Linux Enterprise Server for z Systems
Hello, I will build OpenSSL on SUSE Linux Enterprise Server for z Systems. But, there is not yet the machine for build, so I cannot do actual machine verification. The CPU is not Intel architecture, is probably z/Architecture. I want to know beforehand the appropriate command-line parameters for executing "Configure". Is it right to specify "linux64-s390x" as follows? (1)cd //openssl-1.0.2k (2)./Configure linux64-s390x Thanks in advance. Regards, Manabu -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Does OpenSSL1.0.2d support for Windows 10?
Hello, Does OpenSSL1.0.2d support for Windows 10? Please let me know if you have any problem running on Windows 10. Thanks in advance. Regards, Dang ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
