patchlwIP - A Lightweight TCP/IP stack - Patches: patch #9823, altcp_tls_mbedtls.c: add...


You are not allowed to post comments on this tracker with your current authentication level.

patch #9823: altcp_tls_mbedtls.c: add restartable feature

Submitted by:  Giuseppe Modugno <giusloq>
Submitted on:  Thu 27 Jun 2019 09:57:43 AM UTC  
Category:  apps Priority:  5 - Normal
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Planned Release:  None

Thu 27 Jun 2019 09:57:43 AM UTC, original submission:  

mbedTLS features an option named MBEDTLS_ECP_RESTARTABLE[1] that is very useful in NO_SYS=1 platforms and when ECP calculus takes a long time (as in many modern MCUs without crypto engine). I'm using a Cortex_M3 LPC1768 and the TLS handshake takes around 5-10 seconds.

During this period, in cooperative multitasking, altcp_mbedtls_lower_recv_process() blocks other tasks (except interrupts). The restartable option splits the long calculus in steps and gives the possibility to run other tasks.

Unfortunately altcp_tls_mbedtls isn't compatible with restartable option. Indeed, the return value MBEDTLS_ERR_SSL_CRYPTO_IN_PROGRESS isn't managed.

I tried to add restartable option, please look at the patch. I trigger an already expired timer when mbedtls_handshake() returns CRYPTO_IN_PROGRESS. In the timer handler I call altcp_mbedtls_lower_recv_process() again. If the calculus is yet in progress, the timer is triggered again.

This patch works in my case, but it is experimental and mainly sub-optimal for the following reasons.

1. There's one timer for each TLS session. An optimization could be using a single timer for all TLS sessions, but this means that altcp_tls_mbedtls must trace all TLS sessions (a list?). In my application I have only one TLS client session, so one timer per session isn't so bad.

2. sys_timeout() could assert if we are out of timers.

3. MBEDTLS_ERR_SSL_CRYPTO_IN_PROGRESS can be returned by mbedtls_read() and mbedtls_write() too. I think this happens only occasionally when, during a session, one peer decides to renegotiate something. I don't know how to manage this situation.


Giuseppe Modugno <giusloq>


Attached Files
file #47139:  patch.diff added by giusloq (2KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by giusloq (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-06-27 giusloq Attached File- => Added patch.diff, #47139

    Back to the top

    Powered by Savane 3.5