pico-sdk
pico-sdk copied to clipboard
raspberrypi
Add mbedtls to pico-sdk
Clone mbedtls somewhere and define PICO_MBEDTLS_PATH to point to the absolute path, e.g. export PICO_MBEDTLS_PATH=~/mbedtls
The mbedtls library must be mbedtls-2.28, e.g. git clone [email protected]:Mbed-TLS/mbedtls.git -b mbedtls-2.28
Rebuild the sdk, then link your code to pico_lwip_mbedtls and pico_mbedtls. See tls_client example in pico-examples
Fixes #893
Is it worth adding this as an optional git submodule, like is done with TinyUSB and lwIP ? :shrug:
Is it worth adding this as an optional git submodule, like is done with TinyUSB and lwIP ? 🤷
I think there's a desire not to add mbedtls to the pico-sdk. But I'll let @kilograham comment.
I think there's a desire not to add mbedtls to the pico-sdk.
But it does is pico_lwip_mbedtls -which lives in the SDK- that needs mbedtls...
Downside of having mbedtls in every application instead of in the SDK, is that if you update your lwip stuff to a newer version, that may require a different version of mbedtls, everyone has to update mbedtls in their application again.
I think a git submodule would make things easier.
I tried to do the same based on how it was done in micropython: fork.
note you didn't change kitchen_sink to include the mbed tls headers, which is mostly what it is there for
Done now
Perhaps also move the function to get random numbers mbedtls_hardware_poll() to SDK? As an application developer I would prefer not to have to deal with such things.
Currently is in the example: https://github.com/peterharperuk/pico-examples/commit/450a4d51ae1dd5f571e06c636b1fda1ba80f6ace#diff-3558f7da3c6b3c91dadb7ef47ef16eb3051bb75449d6927cc91df8c6850fa6d7R29 (And personally would think it would be cleaner if it called pico_lwip_random_byte() in a loop, so you have a single random function in the SDK, and not multiple at different places. But that would require that you get rid of the "static" classifier and put it in more public header file https://github.com/raspberrypi/pico-sdk/blob/2e6142b15b8a75c1227dd3edbe839193b2bf9041/src/rp2_common/pico_lwip/random.c )
Agree on moving the random function into the SDK, but probably as a separate PR (src/common/pico_random for the headerandsrc/rp2_common/pico_random` for the impl
Do you want me to add mbedtls as a submodule then?
Yes; i think that is fine, it only looks to be about 15M ... if people can complain we can start suggesting which submodules to init
I'm also curious about threading - mbedtls supports a threading model (basically mutexes)... currently I assume people using it with lwIP would be protected by the lwIP concurrency we provide? i.e. they follow the same rules as for lwip?
Is this good enough, or do we need to provide an implementation of MBEDTLS_THREADING_ALT in some situations?
currently I assume people using it with lwIP would be protected by the lwIP concurrency we provide?
Eh, what concurrency? Note that all your examples use the lwip "raw" API methods, and those are only supposed to be ever called from the main thread/core.
https://www.nongnu.org/lwip/2_0_x/raw_api.html
(lwip does also supports higher level APIs that do offer some thread-safety, but I very much doubt you implemented support for those. Recall that if you want to use those lwip expects a multi-threading OS and that it can have a thread of its own.)
See https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_cyw43_arch/include/pico/cyw43_arch.h
We support the raw API in general, yes either as raw polling, or in "thread-safe background" mode who's main points are to avoid having to do a user polling loop, but also supporting both cores. This requires that we protect the raw API with a mutex. Then we have the full on FreeRTOS support.
Note, the other reason I'm wondering about threading and mbedtls is that ppl might use pico_mbedtls independently of wanting lwip/networking. I think it is fair to see this is pretty fair for now, because they are perhaps not going to be doing both at the same time, and if they are, may not be sharing any keys etc. but still something to think about
I think it is fair to see this is pretty fair for now, because they are perhaps not going to be doing both at the same time, and if they are, may not be sharing any keys etc.
Could be that the random number generator stuff is a problem, if both threads want to do crypthographic stuff that requires random. With that I do not mean mbedtls_hardware_poll(), as that is only used to get some initial entropy. But functions like this that likely have the mutex for a reason: https://github.com/Mbed-TLS/mbedtls/blob/development/library/ctr_drbg.c#L578..L597
Still unlikely to be a problem in practice though.