Move the core state machine of SSLClientSocketNSS into a thread-safe Core

net/third_party/nss/ssl/sslinfo.c

 /* ***** BEGIN LICENSE BLOCK *****
  * Version: MPL 1.1/GPL 2.0/LGPL 2.1
  *
  * The contents of this file are subject to the Mozilla Public License Version
  * 1.1 (the "License"); you may not use this file except in compliance with
  * the License. You may obtain a copy of the License at
  * http://www.mozilla.org/MPL/
  *
  * Software distributed under the License is distributed on an "AS IS" basis,
  * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
@@ skipping 358 matching lines @@
     unsigned int valLen, i;
     SECStatus rv = SECFailure;
 
     ss = ssl_FindSocket(fd);
     if (!ss) {
         SSL_DBG(("%d: SSL[%d]: bad socket in ExportKeyingMaterial",
                  SSL_GETPID(), fd));
         return SECFailure;
     }
 
+    ssl_GetRecvBufLock(ss);

[wtc, 2012/05/30 22:54:29]

The changes to this file should be moved to a separate CL.

Are you sure this function needs to get RecvBufLock?
It doesn't read data from the transport.

[Ryan Sleevi, 2012/05/30 23:20:10]

No, this is important to avoiding the need to modify
SSLClientSocketNSS::ExportKeyingMaterial.
RecvBufLock is the only guard for ss->version, which is meant to be one of the
'atomic longs' but that is dependent on platform and thus not a safe assumption.

SSL3HandshakeLock guards ss->ssl3

[wtc, 2012/05/31 01:23:42]

I studied the functions in sslsecur.c as examples.  They
showed that ss->version seems to be protected by
ssl_Get1stHandshakeLock rather than ssl_GetRecvBufLock.
So I think we should use ssl_Get1stHandshakeLock instead.

We need to add an NSS patch file for these changes.

[Ryan Sleevi, 2012/05/31 01:31:14]

1stHandshakeLock is itself guarded by RecvBufLock. I'll dig through the notes
again, but there were writes to ss->version /before/ 1stHandshakeLock (in
particular, renegotiation, IIRC), hence the broad lock.
Agreed. Wanted to make the changes stick first.

[wtc, 2012/06/01 01:02:38]

1stHandshakeLock is broader than RecvBufLock.

I found places where NSS reads or writes ss->version
while holding only 1stHandshakeLock.  The place where
NSS writes ss->version while holding only 1stHandshakeLock
is in ssl3_SendClientHello, when it copies the version from the
SID structure.

Unless we are modifying ss->version based on info just
received from the peer, we don't need to hold RecvBufLock.

[Ryan Sleevi, 2012/06/04 21:51:50]

ssl3_SendClientHello expects HaveSSL3HandshakeLock.

http://mxr.mozilla.org/security/source/security/nss/lib/ssl/ssl3con.c?mark=39...

ssl3_HandleV2ClientHello (really only for servers) is the one I was thinking of
that didn't have it locked appropriately, because it originates in the SSL2
layer, and thus only has RecvBuf.

Thus, I think this is the correct locking sequence, even though
SSLServerSocketNSS has (not yet?) been ported to use a ref-counted core.

[wtc, 2012/06/04 23:44:58]

I am not suggesting that we remove the ssl_GetSSL3HandshakeLock
call. I am suggesting that we either remove the
ssl_GetRecvBufLock call or replace the ssl_GetRecvBufLock
call with a ssl_Get1stHandshakeLock call.

The RecvBufLock has to be held during ssl3_HandleV2ClientHello
because ssl3_HandleV2ClientHello is using data in
ss->gs.buf to set ss->version.  The RecvBufLock is
used to protect ss->gs.buf, as documented in this
comment:

   PZMonitor *   recvBufLock;	/* locks low level recv buffers. */

All the ssl3_Handle<HandshakeMessate> functions need to
hold the RecvBufLock for this reason.

I think it is enough for SSL_ExportKeyingMaterial to
hold just the SSL3HandshakeLock.

[Ryan Sleevi, 2012/06/05 00:01:59]

Apologies, but I still don't understand why you're suggesting this.

SSL3HandshakeLock is too narrow by itself (doesn't cover the server case)
1stHandshakeLook is too narrow by itself (doesn't cover renegotiation
handshakes)

The only one that covers the entire state machine is RecvBufLock. As you note,
/all/ ssl[23]_Handle<HandshakeMessage> functions need to hold this lock.

The remaining locking is to ensure that the lock ordering (eg: must hold HS
lock, must hold SpecReadLock) is respected, even though RecvBufLock should cover
all of this.

+    ssl_GetSSL3HandshakeLock(ss);
+
     if (ss->version < SSL_LIBRARY_VERSION_3_1_TLS) {
         PORT_SetError(SSL_ERROR_UNSUPPORTED_VERSION);
+        ssl_ReleaseSSL3HandshakeLock(ss);
+        ssl_ReleaseRecvBufLock(ss);
         return SECFailure;
     }
 
     /* construct PRF arguments */
     valLen = SSL3_RANDOM_LENGTH * 2;
     if (hasContext) {
         valLen += 2 /* uint16 length */ + contextLen;
     }
     val = PORT_Alloc(valLen);
     if (!val) {
+        ssl_ReleaseSSL3HandshakeLock(ss);
+        ssl_ReleaseRecvBufLock(ss);
         return SECFailure;
     }
     i = 0;
+
     PORT_Memcpy(val + i, &ss->ssl3.hs.client_random.rand, SSL3_RANDOM_LENGTH);
     i += SSL3_RANDOM_LENGTH;
     PORT_Memcpy(val + i, &ss->ssl3.hs.server_random.rand, SSL3_RANDOM_LENGTH);
     i += SSL3_RANDOM_LENGTH;
+    ssl_ReleaseSSL3HandshakeLock(ss);

[wtc, 2012/05/30 22:54:29]

BUG: this function releases SSL3HandshakeLock twice, here
and on line 428.

[Ryan Sleevi, 2012/05/30 23:20:10]

Well spotted.

+
     if (hasContext) {
         val[i++] = contextLen >> 8;
         val[i++] = contextLen;
         PORT_Memcpy(val + i, context, contextLen);
         i += contextLen;
     }
     PORT_Assert(i == valLen);
 
     /* Allow TLS keying material to be exported sooner, when the master
      * secret is available and we have sent ChangeCipherSpec.
      */
     ssl_GetSpecReadLock(ss);
     if (!ss->ssl3.cwSpec->master_secret && !ss->ssl3.cwSpec->msItem.len) {
         PORT_SetError(SSL_ERROR_HANDSHAKE_NOT_COMPLETED);
         rv = SECFailure;
     } else {
         rv = ssl3_TLSPRFWithMasterSecret(ss->ssl3.cwSpec, label, labelLen, val,
                                          valLen, out, outLen);
     }
     ssl_ReleaseSpecReadLock(ss);
+    ssl_ReleaseSSL3HandshakeLock(ss);
+    ssl_ReleaseRecvBufLock(ss);
 
     PORT_ZFree(val, valLen);
     return rv;
 }