[JBoss JIRA] (MODCLUSTER-554) JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-554?page=com.atlassian.jira.pl... ]
Michal Karm Babacek commented on MODCLUSTER-554:
------------------------------------------------
Gonna move to Wildfly JIRA then.
> JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
> -----------------------------------------------------------------------------
>
> Key: MODCLUSTER-554
> URL: https://issues.jboss.org/browse/MODCLUSTER-554
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.5.Final
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Critical
>
> h3. Preface
> mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem.
> Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl:
> {noformat}
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> {noformat}
> h3. Configuration
> {code}
> <security-realm name="JBossTestServer">
> <server-identities>
> <ssl protocol="openssl.TLS">
> <engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/>
> <keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/>
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/>
> </authentication>
> </security-realm>
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="https">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> <ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/>
> </mod-cluster-config>
> </subsystem>
> [org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {code}
> h3. JVM segfault
> Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...]
> {noformat}
> 12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}causes JVM segfault: {noformat}#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700
> #{noformat}
> Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5
> C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub
> V [libjvm.so+0x657fbb]
> V [libjvm.so+0x6593b7]
> V [libjvm.so+0x659877]
> V [libjvm.so+0x6a9371]
> V [libjvm.so+0x9de335]
> V [libjvm.so+0x9de590]
> V [libjvm.so+0x8a18b2]
> C [libpthread.so.0+0x7aa1]
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub{noformat}
> h3. OpenSSL 1.0.2h
> This is the declaration of the called [SSL_SESSION_get_id|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h...] and this is the definition in [ssl_sess.c|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h/ssl/ssl...]
> h3. Conclusion
> IMHO it wouldn't do any harm to check whether {{session}} ain't NULL before passing it on down to OpenSSL, but it is only the aftermath, not the original cause I suppose. It might be worth checking whether the bug is actually not simply in the mod_cluster java part, in calling {{org.wildfly.openssl.OpenSSLEngine}} with confused protocols/cipher suites.
> Cheers
> -K-
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (MODCLUSTER-554) JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-554?page=com.atlassian.jira.pl... ]
Stuart Douglas resolved MODCLUSTER-554.
---------------------------------------
Resolution: Rejected
This is a Wildfly OpenSSL issue, not a mod_cluster problem
> JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
> -----------------------------------------------------------------------------
>
> Key: MODCLUSTER-554
> URL: https://issues.jboss.org/browse/MODCLUSTER-554
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.5.Final
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Critical
>
> h3. Preface
> mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem.
> Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl:
> {noformat}
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> {noformat}
> h3. Configuration
> {code}
> <security-realm name="JBossTestServer">
> <server-identities>
> <ssl protocol="openssl.TLS">
> <engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/>
> <keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/>
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/>
> </authentication>
> </security-realm>
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="https">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> <ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/>
> </mod-cluster-config>
> </subsystem>
> [org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {code}
> h3. JVM segfault
> Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...]
> {noformat}
> 12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}causes JVM segfault: {noformat}#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700
> #{noformat}
> Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5
> C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub
> V [libjvm.so+0x657fbb]
> V [libjvm.so+0x6593b7]
> V [libjvm.so+0x659877]
> V [libjvm.so+0x6a9371]
> V [libjvm.so+0x9de335]
> V [libjvm.so+0x9de590]
> V [libjvm.so+0x8a18b2]
> C [libpthread.so.0+0x7aa1]
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub{noformat}
> h3. OpenSSL 1.0.2h
> This is the declaration of the called [SSL_SESSION_get_id|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h...] and this is the definition in [ssl_sess.c|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h/ssl/ssl...]
> h3. Conclusion
> IMHO it wouldn't do any harm to check whether {{session}} ain't NULL before passing it on down to OpenSSL, but it is only the aftermath, not the original cause I suppose. It might be worth checking whether the bug is actually not simply in the mod_cluster java part, in calling {{org.wildfly.openssl.OpenSSLEngine}} with confused protocols/cipher suites.
> Cheers
> -K-
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (MODCLUSTER-555) JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
by Michal Karm Babacek (JIRA)
Michal Karm Babacek created MODCLUSTER-555:
----------------------------------------------
Summary: JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
Key: MODCLUSTER-555
URL: https://issues.jboss.org/browse/MODCLUSTER-555
Project: mod_cluster
Issue Type: Bug
Components: Core & Container Integration (Java)
Affects Versions: 1.3.5.Final
Reporter: Michal Karm Babacek
Assignee: Stuart Douglas
Priority: Critical
h3. Preface
mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem.
Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl:
{noformat}
at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
{noformat}
h3. Configuration
{code}
<security-realm name="JBossTestServer">
<server-identities>
<ssl protocol="openssl.TLS">
<engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/>
<keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/>
</ssl>
</server-identities>
<authentication>
<truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/>
</authentication>
</security-realm>
<subsystem xmlns="urn:jboss:domain:modcluster:2.0">
<mod-cluster-config advertise-socket="modcluster" connector="https">
<dynamic-load-provider>
<load-metric type="cpu"/>
</dynamic-load-provider>
<ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/>
</mod-cluster-config>
</subsystem>
[org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
{code}
h3. JVM segfault
Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...]
{noformat}
12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256
at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{noformat}causes JVM segfault: {noformat}#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700
#{noformat}
Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5
C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b
j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
j java.lang.ref.Finalizer$FinalizerThread.run()V+45
v ~StubRoutines::call_stub
V [libjvm.so+0x657fbb]
V [libjvm.so+0x6593b7]
V [libjvm.so+0x659877]
V [libjvm.so+0x6a9371]
V [libjvm.so+0x9de335]
V [libjvm.so+0x9de590]
V [libjvm.so+0x8a18b2]
C [libpthread.so.0+0x7aa1]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
j java.lang.ref.Finalizer$FinalizerThread.run()V+45
v ~StubRoutines::call_stub{noformat}
h3. OpenSSL 1.0.2h
This is the declaration of the called [SSL_SESSION_get_id|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h...] and this is the definition in [ssl_sess.c|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h/ssl/ssl...]
h3. Conclusion
IMHO it wouldn't do any harm to check whether {{session}} ain't NULL before passing it on down to OpenSSL, but it is only the aftermath, not the original cause I suppose. It might be worth checking whether the bug is actually not simply in the mod_cluster java part, in calling {{org.wildfly.openssl.OpenSSLEngine}} with confused protocols/cipher suites.
Cheers
-K-
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (MODCLUSTER-554) JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-554?page=com.atlassian.jira.pl... ]
Michal Karm Babacek updated MODCLUSTER-554:
-------------------------------------------
Description:
h3. Preface
mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem.
Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl:
{noformat}
at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
{noformat}
h3. Configuration
{code}
<security-realm name="JBossTestServer">
<server-identities>
<ssl protocol="openssl.TLS">
<engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/>
<keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/>
</ssl>
</server-identities>
<authentication>
<truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/>
</authentication>
</security-realm>
<subsystem xmlns="urn:jboss:domain:modcluster:2.0">
<mod-cluster-config advertise-socket="modcluster" connector="https">
<dynamic-load-provider>
<load-metric type="cpu"/>
</dynamic-load-provider>
<ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/>
</mod-cluster-config>
</subsystem>
[org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
{code}
h3. JVM segfault
Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...]
{noformat}
12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256
at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{noformat}causes JVM segfault: {noformat}#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700
#{noformat}
Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5
C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b
j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
j java.lang.ref.Finalizer$FinalizerThread.run()V+45
v ~StubRoutines::call_stub
V [libjvm.so+0x657fbb]
V [libjvm.so+0x6593b7]
V [libjvm.so+0x659877]
V [libjvm.so+0x6a9371]
V [libjvm.so+0x9de335]
V [libjvm.so+0x9de590]
V [libjvm.so+0x8a18b2]
C [libpthread.so.0+0x7aa1]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
j java.lang.ref.Finalizer$FinalizerThread.run()V+45
v ~StubRoutines::call_stub{noformat}
h3. OpenSSL 1.0.2h
This is the declaration of the called [SSL_SESSION_get_id|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h...] and this is the definition in [ssl_sess.c|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h/ssl/ssl...]
h3. Conclusion
IMHO it wouldn't do any harm to check whether {{session}} ain't NULL before passing it on down to OpenSSL, but it is only the aftermath, not the original cause I suppose. It might be worth checking whether the bug is actually not simply in the mod_cluster java part, in calling {{org.wildfly.openssl.OpenSSLEngine}} with confused protocols/cipher suites.
Cheers
-K-
was:
h3. Preface
mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem.
Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl:
{noformat}
at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
{noformat}
h3. Configuration
{code}
<security-realm name="JBossTestServer">
<server-identities>
<ssl protocol="openssl.TLS">
<engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/>
<keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/>
</ssl>
</server-identities>
<authentication>
<truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/>
</authentication>
</security-realm>
<subsystem xmlns="urn:jboss:domain:modcluster:2.0">
<mod-cluster-config advertise-socket="modcluster" connector="https">
<dynamic-load-provider>
<load-metric type="cpu"/>
</dynamic-load-provider>
<ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/>
</mod-cluster-config>
</subsystem>
[org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
{code}
h3. JVM segfault
Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...]
{noformat}
12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256
at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{noformat}causes JVM segfault: {noformat}#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700
#{noformat}
Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5
C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b
j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
j java.lang.ref.Finalizer$FinalizerThread.run()V+45
v ~StubRoutines::call_stub
V [libjvm.so+0x657fbb]
V [libjvm.so+0x6593b7]
V [libjvm.so+0x659877]
V [libjvm.so+0x6a9371]
V [libjvm.so+0x9de335]
V [libjvm.so+0x9de590]
V [libjvm.so+0x8a18b2]
C [libpthread.so.0+0x7aa1]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
j java.lang.ref.Finalizer$FinalizerThread.run()V+45
v ~StubRoutines::call_stub{noformat}
> JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
> -----------------------------------------------------------------------------
>
> Key: MODCLUSTER-554
> URL: https://issues.jboss.org/browse/MODCLUSTER-554
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.5.Final
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Critical
>
> h3. Preface
> mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem.
> Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl:
> {noformat}
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> {noformat}
> h3. Configuration
> {code}
> <security-realm name="JBossTestServer">
> <server-identities>
> <ssl protocol="openssl.TLS">
> <engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/>
> <keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/>
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/>
> </authentication>
> </security-realm>
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="https">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> <ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/>
> </mod-cluster-config>
> </subsystem>
> [org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {code}
> h3. JVM segfault
> Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...]
> {noformat}
> 12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}causes JVM segfault: {noformat}#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700
> #{noformat}
> Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5
> C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub
> V [libjvm.so+0x657fbb]
> V [libjvm.so+0x6593b7]
> V [libjvm.so+0x659877]
> V [libjvm.so+0x6a9371]
> V [libjvm.so+0x9de335]
> V [libjvm.so+0x9de590]
> V [libjvm.so+0x8a18b2]
> C [libpthread.so.0+0x7aa1]
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub{noformat}
> h3. OpenSSL 1.0.2h
> This is the declaration of the called [SSL_SESSION_get_id|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h...] and this is the definition in [ssl_sess.c|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h/ssl/ssl...]
> h3. Conclusion
> IMHO it wouldn't do any harm to check whether {{session}} ain't NULL before passing it on down to OpenSSL, but it is only the aftermath, not the original cause I suppose. It might be worth checking whether the bug is actually not simply in the mod_cluster java part, in calling {{org.wildfly.openssl.OpenSSLEngine}} with confused protocols/cipher suites.
> Cheers
> -K-
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (MODCLUSTER-554) JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-554?page=com.atlassian.jira.pl... ]
Michal Karm Babacek updated MODCLUSTER-554:
-------------------------------------------
Component/s: Core & Container Integration (Java)
> JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
> -----------------------------------------------------------------------------
>
> Key: MODCLUSTER-554
> URL: https://issues.jboss.org/browse/MODCLUSTER-554
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.5.Final
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Critical
>
> h3. Preface
> mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem.
> Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl:
> {noformat}
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> {noformat}
> h3. Configuration
> {code}
> <security-realm name="JBossTestServer">
> <server-identities>
> <ssl protocol="openssl.TLS">
> <engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/>
> <keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/>
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/>
> </authentication>
> </security-realm>
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="https">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> <ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/>
> </mod-cluster-config>
> </subsystem>
> [org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {code}
> h3. JVM segfault
> Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...]
> {noformat}
> 12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}causes JVM segfault: {noformat}#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700
> #{noformat}
> Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5
> C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub
> V [libjvm.so+0x657fbb]
> V [libjvm.so+0x6593b7]
> V [libjvm.so+0x659877]
> V [libjvm.so+0x6a9371]
> V [libjvm.so+0x9de335]
> V [libjvm.so+0x9de590]
> V [libjvm.so+0x8a18b2]
> C [libpthread.so.0+0x7aa1]
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (MODCLUSTER-554) JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-554?page=com.atlassian.jira.pl... ]
Michal Karm Babacek updated MODCLUSTER-554:
-------------------------------------------
Affects Version/s: 1.3.5.Final
> JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
> -----------------------------------------------------------------------------
>
> Key: MODCLUSTER-554
> URL: https://issues.jboss.org/browse/MODCLUSTER-554
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.3.5.Final
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Critical
>
> h3. Preface
> mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem.
> Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl:
> {noformat}
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> {noformat}
> h3. Configuration
> {code}
> <security-realm name="JBossTestServer">
> <server-identities>
> <ssl protocol="openssl.TLS">
> <engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/>
> <keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/>
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/>
> </authentication>
> </security-realm>
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="https">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> <ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/>
> </mod-cluster-config>
> </subsystem>
> [org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {code}
> h3. JVM segfault
> Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...]
> {noformat}
> 12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}causes JVM segfault: {noformat}#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700
> #{noformat}
> Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5
> C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub
> V [libjvm.so+0x657fbb]
> V [libjvm.so+0x6593b7]
> V [libjvm.so+0x659877]
> V [libjvm.so+0x6a9371]
> V [libjvm.so+0x9de335]
> V [libjvm.so+0x9de590]
> V [libjvm.so+0x8a18b2]
> C [libpthread.so.0+0x7aa1]
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (MODCLUSTER-554) JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
by Michal Karm Babacek (JIRA)
Michal Karm Babacek created MODCLUSTER-554:
----------------------------------------------
Summary: JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
Key: MODCLUSTER-554
URL: https://issues.jboss.org/browse/MODCLUSTER-554
Project: mod_cluster
Issue Type: Bug
Reporter: Michal Karm Babacek
Assignee: Stuart Douglas
Priority: Critical
h3. Preface
mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem.
Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl:
{noformat}
at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
{noformat}
h3. Configuration
{code}
<security-realm name="JBossTestServer">
<server-identities>
<ssl protocol="openssl.TLS">
<engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/>
<keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/>
</ssl>
</server-identities>
<authentication>
<truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/>
</authentication>
</security-realm>
<subsystem xmlns="urn:jboss:domain:modcluster:2.0">
<mod-cluster-config advertise-socket="modcluster" connector="https">
<dynamic-load-provider>
<load-metric type="cpu"/>
</dynamic-load-provider>
<ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/>
</mod-cluster-config>
</subsystem>
[org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
{code}
h3. JVM segfault
Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...]
{noformat}
12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256
at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{noformat}causes JVM segfault: {noformat}#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700
#{noformat}
Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5
C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b
j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
j java.lang.ref.Finalizer$FinalizerThread.run()V+45
v ~StubRoutines::call_stub
V [libjvm.so+0x657fbb]
V [libjvm.so+0x6593b7]
V [libjvm.so+0x659877]
V [libjvm.so+0x6a9371]
V [libjvm.so+0x9de335]
V [libjvm.so+0x9de590]
V [libjvm.so+0x8a18b2]
C [libpthread.so.0+0x7aa1]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
j java.lang.ref.Finalizer$FinalizerThread.run()V+45
v ~StubRoutines::call_stub{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (MODCLUSTER-514) MemManagerFile doesn't take relative paths
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-514?page=com.atlassian.jira.pl... ]
Michal Karm Babacek commented on MODCLUSTER-514:
------------------------------------------------
THX for a heads up. Gonna bump its priority on my list.
> MemManagerFile doesn't take relative paths
> ------------------------------------------
>
> Key: MODCLUSTER-514
> URL: https://issues.jboss.org/browse/MODCLUSTER-514
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.3.1.Final, 1.2.13.Final
> Reporter: Michal Karm Babacek
> Assignee: Michal Karm Babacek
> Priority: Minor
>
> This is mostly a user experience issue.
> According to what {{LoadModule}} and other directives do, one would expect that a path without leading slash is a relative one to the server root.
> h3. Setting
> * {{MemManagerFile cache/mod_cluster}}
> * {{ServerRoot "/home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build"}}
> h3. Expected result
> {noformat}
> /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/cache/mod_cluster/
> manager.balancer.balancers manager.context.contexts manager.domain.domain manager.host.hosts manager.node.nodes
> manager.balancer.balancers.lock manager.context.contexts.lock manager.domain.domain.lock manager.host.hosts.lock manager.node.nodes.lock
> manager.balancer.balancers.slotmem manager.context.contexts.slotmem manager.domain.domain.slotmem manager.host.hosts.slotmem manager.node.nodes.slotmem
> {noformat}
> h3. Actual result
> {noformat}
> /cache/mod_cluster/
> manager.balancer.balancers manager.context.contexts manager.domain.domain manager.host.hosts manager.node.nodes
> manager.balancer.balancers.lock manager.context.contexts.lock manager.domain.domain.lock manager.host.hosts.lock manager.node.nodes.lock
> manager.balancer.balancers.slotmem manager.context.contexts.slotmem manager.domain.domain.slotmem manager.host.hosts.slotmem manager.node.nodes.slotmem
> {noformat}
> and an empty directory is created in the directory from which the httpd root process was started:
> {{/home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/bin/cache/mod_cluster/}}.
> h3. Fix
> * leading {{/}} should mean absolute path
> * without leading {{/}} should be relative to ServerRoot
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (MODCLUSTER-514) MemManagerFile doesn't take relative paths
by Coty Sutherland (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-514?page=com.atlassian.jira.pl... ]
Coty Sutherland commented on MODCLUSTER-514:
--------------------------------------------
Implementing a fix for this would make mod_proxy_cluster behave like other modules and fit with the expectations that httpd configuration sets :)
> MemManagerFile doesn't take relative paths
> ------------------------------------------
>
> Key: MODCLUSTER-514
> URL: https://issues.jboss.org/browse/MODCLUSTER-514
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.3.1.Final, 1.2.13.Final
> Reporter: Michal Karm Babacek
> Assignee: Michal Karm Babacek
> Priority: Minor
>
> This is mostly a user experience issue.
> According to what {{LoadModule}} and other directives do, one would expect that a path without leading slash is a relative one to the server root.
> h3. Setting
> * {{MemManagerFile cache/mod_cluster}}
> * {{ServerRoot "/home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build"}}
> h3. Expected result
> {noformat}
> /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/cache/mod_cluster/
> manager.balancer.balancers manager.context.contexts manager.domain.domain manager.host.hosts manager.node.nodes
> manager.balancer.balancers.lock manager.context.contexts.lock manager.domain.domain.lock manager.host.hosts.lock manager.node.nodes.lock
> manager.balancer.balancers.slotmem manager.context.contexts.slotmem manager.domain.domain.slotmem manager.host.hosts.slotmem manager.node.nodes.slotmem
> {noformat}
> h3. Actual result
> {noformat}
> /cache/mod_cluster/
> manager.balancer.balancers manager.context.contexts manager.domain.domain manager.host.hosts manager.node.nodes
> manager.balancer.balancers.lock manager.context.contexts.lock manager.domain.domain.lock manager.host.hosts.lock manager.node.nodes.lock
> manager.balancer.balancers.slotmem manager.context.contexts.slotmem manager.domain.domain.slotmem manager.host.hosts.slotmem manager.node.nodes.slotmem
> {noformat}
> and an empty directory is created in the directory from which the httpd root process was started:
> {{/home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/bin/cache/mod_cluster/}}.
> h3. Fix
> * leading {{/}} should mean absolute path
> * without leading {{/}} should be relative to ServerRoot
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (MODCLUSTER-522) Memory leak in processing MCMP, wrong apr pool used for allocation
by Lorenzo Finetto (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-522?page=com.atlassian.jira.pl... ]
Lorenzo Finetto commented on MODCLUSTER-522:
--------------------------------------------
Thank you Michal.
I'll need the Windows 64bit version and I can wait the official release. I'll be thankful if you could also post the right link to download the release. I have to say that it's not so easy to find.
Thank you again
Cheers
Lorenzo
> Memory leak in processing MCMP, wrong apr pool used for allocation
> ------------------------------------------------------------------
>
> Key: MODCLUSTER-522
> URL: https://issues.jboss.org/browse/MODCLUSTER-522
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.3.1.Final, 2.0.0.Alpha1
> Environment: Solaris 10 x86_64, RHEL 6, Fedora 24, httpd 2.4.6, httpd 2.4.20
> Reporter: Michal Karm Babacek
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 1.3.5.Final
>
> Attachments: mod_cluster-mem.jpg, mod_cluster-mem1.jpg
>
>
> There seems to be a wrong apr pool used for processing certain MCMP commands. We should use short life span pools for immediate processing and server-lifetime pools only for really persistent configuration. In the current state, with 20+ tomcat workers (1 alias and 1 context each) and virtually no client requests, we could see slow, but steady growth of heap allocated memory.
> TODO: Investigate the offending logic, make sure we ain't using long-lived pools for immediate processing.
> Originally discovered by: [~j_sykora] and [~jmsantuci]
> Illustrative memory overview - with constant number of Tomcats:
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years