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,

--
Gilles Peskine
Mbed TLS developer

On 20/07/2021 22:10, Shariful Alam wrote:
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 a straight-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_C
>
> But 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