Re: [mbed-tls] How to setup config.h to make memory_buffer_alloc_init() thread-safe?

-- 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 > mailto: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 https://pastebin.com/uyW3vknt https://pastebin.com/uyW3vknt> > > > > Thanks, > > Shariful > > > > -- > mbed-tls mailing list > mbed-tls@lists.trustedfirmware.org > mailto:mbed-tls@lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >