@Iv4n @BDub The biggest memory usage is definitely in the RSA handshake. Darn that big number math. The price we pay for security. I don't recall how much heap it claims max, but it's the bulk of the ~10K claimed by . Here are some pointers to relevant code for anyone who feels like digging into memory usage improvements.
The only call to allocate heap (
malloc) in the entire firmware is in TropicSSL's
This gets called in
init_rsa_context_with_public_key when we send the initial message encrypted for the server:
It's also called (
init_rsa_context_with_private_key) when the Core is processing the encrypted reply from the server in
set_key, both in
Our malloc/free implementation is extremely simplistic right now and does not handle fragmentation. See our stub for
As I write this I'm noticing that the description for
mallopt in the newlib docs says:
... releasing it back to the system in
free (the space is released by calling
_sbrk_r with a negative argument)
We have a stub for
_sbrk but not one for
_sbrk_r, though this might all be delegated under the hood. If you know otherwise, by all means submit a PR.
As always, pull requests welcome. @satishgn has been working lately on trying to statically allocate a buffer for the RSA math and free it up afterward. Not there yet, but we've got our eyes on the prize.