Hi Gilles, Thank you very much, for your reply. Sorry to bother you again. I am trying to follow your instructions. I have a question regarding your suggestions.
You said "applications call mbedtls_memory_buffer_alloc_init() in the startup code of the initial thread, before creating other threads. The alloc/free functions are thread-safe, but the initialization and deinitialization functions aren't."
I'm a little confused here. Say, if I call mbedtls_memory_buffer_alloc_init() with a buffer in the main thread, how did all other threads use this memory (or how do all the threads know which memory block to use)?
After calling mbedtls_memory_buffer_alloc_init() in the main thread, I can get the address of the buffer and pass it to the threads, do I have to call mbedtls_memory_buffer_alloc_init() again inside each thread?
Thanks, Shariful
On Mon, Jul 19, 2021 at 3:48 AM Gilles Peskine via mbed-tls < mbed-tls@lists.trustedfirmware.org> wrote:
Hi Shariful,
First, please note that the library called PolarSSL with functions like rsa_private() and memory_buffer_alloc_init() has not been supported for several years. You should upgrade to Mbed TLS, with functions like mbedtls_rsa_private() and mbedtls_memory_buffer_alloc_init(). That being said, the memory_buffer_alloc module works in the same way.
Normally, applications call mbedtls_memory_buffer_alloc_init() in the startup code of the initial thread, before creating other threads. The alloc/free functions are thread-safe, but the initialization and deinitialization functions aren't. If you must call mbedtls_memory_buffer_alloc_init() after creating other threads, make sure that no thread calls mbedtls_calloc until mbedtls_memory_buffer_alloc_init() has returned.
The same principle applies to other parts of Mbed TLS that are thread-safe. For example, only the RSA operations (encryption, decryption, signature, verification, and also the low-level functions mbedtls_rsa_public() and mbedtls_rsa_private()) are protected. So you must finish setting up the RSA key inside one thread before you pass a pointer to other threads. Similarly, only mbedtls_xxx_drbg_random() is thread-safe, and the RNG setup (including mbedtls_xxx_drgb_seed()) should be done as part of the initial application startup.
Finally, note that mbedtls_rsa_private() alone cannot decrypt a message: all it does it to apply the private key operation. To decrypt a simple message encrypted with RSA-OAEP, call mbedtls_rsa_rsaes_oaep_decrypt() or mbedtls_rsa_pkcs1_decrypt() with a key set up for MBEDTLS_RSA_PKCS_V21 encoding. To use the legacy PKCS#1v1.5 mechanism, call mbedtls_rsa_rsaes_pkcs1_v15_decrypt() or mbedtls_rsa_pkcs1_decrypt() with a key set up for .MBEDTLS_RSA_PKCS_V15. To decrypt a message using a RSA FDH hybrid scheme, you do need to call mbedtls_rsa_private() since Mbed TLS doesn't support it natively, but what this gives you is the intermediate secret from which you then need to derive a symmetric key, not the message itself.
Best regards,
-- Gilles Peskine Mbed TLS developer
On 18/07/2021 07:16, Shariful Alam via mbed-tls wrote:
Hello, I have a simple example code to decrypt an encrypted message using *rsa_private()*. I use *memory_buffer_alloc_init(), *in order to use a static memory for the computation. I want to run my code concurrently. My code works with a single pthread. However, when I try to run more than one thread my program fails to decrypt.
** I check the same code without *memory_buffer_alloc_init(), *it works concurrently, without any issues at all.
Therefore, I believe, the issue that I'm facing is coming from the use of static memory(e.g. *memory_buffer_alloc_init()*). The documentation of memorry_buffer_alloc.h shows,
/** * \brief Initialize use of stack-based memory allocator. * The stack-based allocator does memory management inside the * presented buffer and does not call malloc() and free(). * It sets the global polarssl_malloc() and polarssl_free() pointers * to its own functions. * (Provided polarssl_malloc() and polarssl_free() are thread-safe if * POLARSSL_THREADING_C is defined) * * \note This code is not optimized and provides astraight-forward
* implementation of a stack-based memory allocator. * * \param buf buffer to use as heap * \param len size of the buffer * * \return 0 if successful */So, I added the following configuration to the *config.h* file
1. #define POLARSSL_THREADING_PTHREAD 2. #define POLARSSL_THREADING_CBut I'm still getting errors while decrypting. Any help on how to fix this? or what else should I add into the config.h file to make *memory_buffer_alloc_init() *thread-safe? Here is my sample code: https://pastebin.com/uyW3vknt https://pastebin.com/uyW3vknt
Thanks, Shariful
-- mbed-tls mailing list mbed-tls@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
Hi Shariful,
You just call mbedtls_calloc() (or let other functions call it). It will use the memory pool set by mbedtls_memory_buffer_alloc_init().
The memory_buffer_alloc module does not support multiple memory pools. If you want a separate pool for each thread's allocation for performance reasons on a multicore system, you'd better rely on your platform's built-in calloc(). It's likely to be fined-tuned for multicore operation. The built-in allocator in Mbed TLS is intended for highly resource-constrained systems where the basic platform doesn't even include an allocator.
Best regards,
mbed-tls@lists.trustedfirmware.org
-
Gilles Peskine -
Shariful Alam