Skip to content

feat: build against mbedtls-rs-sys#64

Draft
scootermon wants to merge 6 commits intoesp-rs:mainfrom
inomotech-foss:feat/external-mbedtls
Draft

feat: build against mbedtls-rs-sys#64
scootermon wants to merge 6 commits intoesp-rs:mainfrom
inomotech-foss:feat/external-mbedtls

Conversation

@scootermon
Copy link
Contributor

@scootermon scootermon commented Mar 7, 2026

See: esp-rs/mbedtls-rs#111

Closes: #61

I tested this using the good old SRP example and everything appears to be working nicely :)

EDIT: Patch no longer needed due to submodule update.

See #64 (comment)

This currently requires a patch to the openthread submodule:

diff --git a/src/core/crypto/mbedtls.cpp b/src/core/crypto/mbedtls.cpp
index 11d39dd21..a05d5cbe1 100644
--- a/src/core/crypto/mbedtls.cpp
+++ b/src/core/crypto/mbedtls.cpp
@@ -46,6 +46,7 @@
 #include "common/code_utils.hpp"
 #include "common/error.hpp"
 #include "common/heap.hpp"
+#include "common/logging.hpp"
 #include "common/random.hpp"
 
 namespace ot {

This is because our mbedtls is compiled with MBEDTLS_DEBUG_C enabled.
Apparently this hasn't been tested in a while. This define causes OpenThread's code to use OPENTHREAD_CONFIG_LOG_LEVEL, which is undefined without the include.

We probably want to disable the debug stuff for release builds anyway, but we should still fix this issue in OT's code.

@scootermon
Copy link
Contributor Author

scootermon commented Mar 7, 2026

So apparently the build issue has already been fixed upstream in openthread/openthread#11766. This PR was merged about a month after the 2025-06-12 reference tag :/

EDIT: Now the CI is unhappy because it managed to uncover a latent issue in the mbedtls-rs code :) See: esp-rs/mbedtls-rs#113

@scootermon scootermon force-pushed the feat/external-mbedtls branch from 2e97364 to 01ccf21 Compare March 7, 2026 19:45
@scootermon
Copy link
Contributor Author

scootermon commented Mar 8, 2026

So OpenThread configures its vendored MbedTLS to use the OT heap (which is backed by a static variable).
Our MbedTLS currently simply relies on the global calloc / free.

Since we want to allow mbedtls-rs to remain general purpose I feel like we should use the following approach:

Compile mbedtls with MBEDTLS_PLATFORM_MEMORY. This removes the need for calloc and free from mbedtls. Instead, it now relies on us calling mbedtls_platform_set_calloc_free to provide these functions. This is exactly what OT already does with its vendored copy of mbedtls!

In an ideal world we could now offer the option to attach mbedtls to the OT heap again using mbedtls_platform_set_calloc_free(Heap::CAlloc, Heap::Free). Unfortunately Heap::CAlloc and Heap::Free are OT internal functions. There are no public C bindings for OT's heap.

So step two is then to also tell OT OPENTHREAD_CONFIG_HEAP_EXTERNAL_ENABLE, which replaces its own heap implementation with otPlatCAlloc and otPlatFree. This allows us to fully shift the dynamic memory management into Rust and gives full control to the user without having to fuss around with compile-time options.
The user could decide to use the global allocator for both mbedtls and OT, or a dedicated buffer-backed allocator for each of them.

This will be quite the undertaking, so as an intermediary solution we can start with only enabling MBEDTLS_PLATFORM_MEMORY and telling OT to take ownership of mbedtls by setting OPENTHREAD_CONFIG_ENABLE_BUILTIN_MBEDTLS_MANAGEMENT. This define controls whether OT ends up injecting its allocation functions into mbedtls:

https://github.com/openthread/openthread/blob/1b43fe6694d6c13ab02648a94fa138534b27dd56/src/core/crypto/mbedtls.cpp#L62-L64

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Compile against mbedtls-rs-sys crate instead of using openthread's vendored version

1 participant