Just allocate what's needed for SSL write buffers.
When we refactored all the buffering logic, we retained upstream
OpenSSL's allocation patterns. In particular, we always allocated fixed
size write buffer, even though, unlike when reading, we trivially know a
tighter bound (namely however much we happen to be writing right now).
Since the cutoff for when Windows' malloc starts having a hard time is
just below the TLS maximum record size, do the more natural thing of
allocating what we need to hold outgoing ciphertext.
(This only does anything to the write half. Read half is a bit more
involved.)
BUG=chromium:524258
Change-Id: I0165f9ce822b9cc413f3c77e269e6154160537a7
Reviewed-on: https://boringssl-review.googlesource.com/14405
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
diff --git a/ssl/ssl_buffer.c b/ssl/ssl_buffer.c
index c27db8b..aefc044 100644
--- a/ssl/ssl_buffer.c
+++ b/ssl/ssl_buffer.c
@@ -225,26 +225,7 @@
return 0;
}
- size_t header_len = ssl_seal_align_prefix_len(ssl);
-
- /* TODO(davidben): This matches the original behavior in keeping the malloc
- * size consistent. Does this matter? |cap| could just be |max_len|. */
- size_t cap = SSL3_RT_MAX_PLAIN_LENGTH + SSL3_RT_SEND_MAX_ENCRYPTED_OVERHEAD;
- if (SSL_is_dtls(ssl)) {
- cap += DTLS1_RT_HEADER_LENGTH;
- } else {
- cap += SSL3_RT_HEADER_LENGTH;
- if (ssl->mode & SSL_MODE_CBC_RECORD_SPLITTING) {
- cap += SSL3_RT_HEADER_LENGTH + SSL3_RT_SEND_MAX_ENCRYPTED_OVERHEAD;
- }
- }
-
- if (max_len > cap) {
- OPENSSL_PUT_ERROR(SSL, SSL_R_BUFFER_TOO_SMALL);
- return 0;
- }
-
- if (!setup_buffer(buf, header_len, cap)) {
+ if (!setup_buffer(buf, ssl_seal_align_prefix_len(ssl), max_len)) {
return 0;
}
*out_ptr = buf->buf + buf->offset;
