Hi Nick,
A TLS stack in 6kB of RAM sounds impressive, congratulations!
We'd certainly be interested in all the improvements you can contribute.
The process is documented in CONTRIBUTING.md
(https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md). I
just need to warn you that the limiting factor is reviewers' time. For a
significant contribution, it may take a while before the Mbed TLS team
can look at it in detail. Small patches are usually easier than large
ones: if something only takes half an hour to review, someone will
probably do it when they're stuck on some other task. If a review takes
several days, it needs to be scheduled.
It would probably be better to discuss the general nature of the changes
on this mailing list first. Is a new compilation option needed? Is an
API change needed? What is the risk that the change might break existing
code? How is the new code tested? etc.
Which version of Mbed TLS have you been using? We've made a few changes
that are of interest to low-memory platforms recently, such as the
option MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH to resize SSL buffers after
the handshake (new in 2.22).
I don't know what the issue with the incoming SSL packet header length
could be. If you could give precise steps to reproduce the issue, this
would be very helpful. Eventually we'd want to construct a test in
tests/ssl-opt.sh for this.
--
Gilles Peskine
Mbed TLS developer
On 17/07/2020 21:00, Nick Setzer via mbed-tls wrote:
>
> Hi, I have been working with Mbed TLS for the last 6 months in an
> extremely low memory use case. This library has been an absolute joy
> to work with because of how flexible it is. I have an interesting use
> case with how little RAM I have to work with (around 6kb on one
> microprocessor) and I have made some changes that I thought would be
> of interest. I'm not sure if I should submit them as a single
> changeset or a set of changes. I'll describe the changes and if there
> is interest I can clean them up for submission.
>
> The first change that I made was for a scenario with two
> microprocessors communicating over a UART. I was already using TLS
> offloading so that the private key was on one processor (with only 6kb
> of RAM free) and the SSL context stored on the other. I required
> generating a CSR and thus made some changes to the CSR code to be able
> to generate the CSR using a similar private key offloading strategy.
>
> I found an issue with downloading firmware for OTA from openssl web
> servers. This is a little tricky to describe. The server was not
> responsive to requests for reducing the max fragment length, which
> forced me to use MBEDTLS_SSL_MAX_CONTENT_LEN set to 16384. But I
> needed to have multiple ssl sessions open for other activities and did
> not have enough RAM to hold multiple large buffers. I have made a set
> of changes to allow setting the content length when the ssl context is
> initialized, as well as setting different IN and OUT content lengths
> to save memory. This change allowed me to set up one session with 16kb
> for the IN content length, and then 4kb for OUT content length, while
> a second session could use 2kb for a total of 24kb instead of 64kb.
>
> Related to the openssl issue, I found that the incoming ssl packet
> header length can sometimes be 8 or 16 bytes larger than expected
> depending on which AES method is selected. I'm not actually sure what
> the best way to solve this is. One way may be to change
> MBEDTLS_SSL_HEADER_LEN from 13 to 29 bytes. However I ended up solving
> it by adding 16 to both MBEDTLS_SSL_IN_BUFFER_LEN and
> MBEDTLS_SSL_OUT_BUFFER_LEN. This way I could handle the larger ssl
> header as well as receive the content body.
>
> If these three changes sound interesting I can start work on cleaning
> up the code to be less specific to my company and then submit the
> changes. Also I would like to know if there is any process I should be
> following when submitting these changes.
>
> Thanks,
>
> Nick Setzer
> SimpliSafe, Inc.
> 294 Washington Street, 9th Floor
> Boston, MA 02108
>
Gilles Peskine