SSL read interface with less data copies

[attilamolnar]

mbedtls_ssl_read() contains a call to memcpy() which copies the data from the internal mbedtls_ssl_context buffer to the user supplied buffer. This copy is not necessary and could be avoided by having a different interface for SSL reads. To achieve this, the basic idea is that the application gets a pointer to the internal mbedTLS buffer and the number of available bytes, accesses the data directly and then calls an mbedTLS function to let the library know it finished processing the data.

With this functionality, applications could avoid a copy entirely if the incoming data can be processed in-place. It also allows them to inspect the data first in case they do need to copy it, letting them decide which part of the data to copy (e.g. some non-fixed size message headers may not need to be copied, only the body which begins at an offset only known after looking at the headers).

From a quick look this can be implemented in mbedTLS relatively simply because of the way mbedtls_ssl_read() is structured: first it does some work independently of the values of buf and len, then it calls memcpy() and then it alters the internal state in light of the number of bytes consumed. This means splitting up mbedtls_ssl_read() into smaller functions would probably accomplish most of the work required to implement this.

GnuTLS has similar functionality from version 3.3.5, see gnutls_record_recv_packet, in http://gnutls.org/manual/html_node/Core-TLS-API.html#Core-TLS-API.

Let me know if you are interested in this and I'll be glad to work on it.

[ciarmcom]

ARM Internal Ref: IOTSSL-818

[pjbakker]

If splitting mbedtls_ssl_read() into smaller functions in a clean way, while keeping the mbedtls_ssl_read() 'wrapper' in place and with identical behaviour, provides this capability, we would be interested.