Memory allocation problem when mpi_exp_mod method execution of RSA API

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

We are implementing the following scenarios, using the WICED Smart tag(BCM20737)

1. placing the RSA-2048 encryption key to WICED Smart tag.

2. Transfer the encrypted data to WICED Smart tag on smartphone.

3. WICED Smart tag is to decrypt the data using the key.

4. sends the decoded data to smartphone.


implement the following sources have to decrypt the data in the tag.

The following sources are implemented by reference to such methods of PolarSSL rsa_init, rsa_public ....

int Ext_ebt_tnpble_sign(unsigned char *in, size_t inlen, unsigned char *out, size_t *outlen)

{

  ble_trace0("Ext_ebt_tnpble_sign start");

  int ret = 0;

  mpi x, c, r;

  mpi_init(&c);

  mpi_init(&r);

  mpi_init(&x);

  ble_trace0("mpi_init end");

  ble_trace1("free memory : %d", cfa_mm_MemFreeBytes());

  if ((ret = mpi_read_binary(&c, in, inlen)) != 0) {

  ble_trace1("free memory : %d", cfa_mm_MemFreeBytes());

  ble_trace3("%d, %d %d\n", __LINE__, ret, inlen);

  ble_tracen(in, inlen);

  goto cleanup;

  }

  ble_trace0("mpi_read_binary ok");

  ble_trace0("mpi_exp_mod start");

  if ((ret = mpi_exp_mod(&x, &c, &s, &n, &r)) != 0) {

  // int mpi_exp_mod( mpi *X, const mpi *A, const mpi *E, const mpi *N, mpi *_RR );

  ble_trace2("%d, %d\n", __LINE__, ret);

  goto cleanup;

  }

  ble_trace0("mpi_exp_mod ok");

  if ((ret = mpi_write_binary(&x, out, *outlen)) != 0) {

  ble_trace2("%d, %d\n", __LINE__, ret);

  goto cleanup;

  }

  ble_trace0("mpi_write_binary ok");

cleanup:

  mpi_free(&c);

  mpi_free(&x);

  mpi_free(&r);

  if (ret != 0)

  return ret;

  return 0;

}

Run the mpi_read_binary.... had been returned to -16.

These values are defined in bignum.h as follows:

bignum.h
#define POLARSSL_ERR_MPI_MALLOC_FAILED                    -0x0010  /**< Memory allocation failed. */

So we add the following logic to APPLICATION_INIT, create method.

  // RSA stack requires to increase the stack size.  Make it 4K.

  blecm_SetApplicationThreadStackSizeInWords(1024);

  // Also RSA code requires a bit larger data size than default 264 bytes.

  cfa_mm_ConfigureMemoryPool(CFA_MM_POOL_2, 524, 35);


  // to verify that RSA does not corrupt the stack, initialize the stack checking.

  // Actual check is called after RSA is done with the signature verification.

  blecm_StackCheckInit();

  // register memory management function

  brcmcryptoglue_set_allocator(myAlloc);

  brcmcryptoglue_set_deallocator(cfa_mm_Free);

and... implemented a myAlloc to debug the allocation process.

void* myAlloc(UINT32 size)

{

    ble_trace1("Alloc(%u)", size);

    void* nptr = cfa_mm_Alloc(size);

    if (nptr == NULL)

          ble_trace0("unable to alloc!!");

    return nptr;

}


Increasing the buffer size has been increased allocation of cfa_mm_ConfigureMemoryPool number.

But still it responded to -16.

This application has been terminated without a return response codes do set the buffer size value to 40.

Is it possible to use the RSA2048 in the tag?

Attach a debug log and source. very simple application only rsa logic

------------------------------------------------------------------------------------------------------

15:38:08 - 020106030304000409bb8104

15:38:08 - 020a81

15:38:08 - Ext_ebt_tnpble_init

15:38:08 - debug mod :

15:38:08 - 9b02c2c12f1a8df42cf3902b8b607632

15:38:08 - 3e09c3ea4d331b79eabb01f41d9d5297

15:38:08 - 7a36da3c7abb839ab7570cab59ae3b71

15:38:08 - 1278f164ef1c2fc5ad727066df793ed7

15:38:08 - afaca88a70e5dfd6db46cad2694b1133

15:38:08 - cd05007c0f1392cb01b6c4400a185468

15:38:08 - 3695bdf6553b95ff0e81459b4d0d4bab

15:38:08 - 94ab71e54de89b0fc673a072d1182062

15:38:08 - fdbc35ffba025dc0456c1bd2da01bce5

15:38:08 - dd1df2fc8ac6ad225b3dd157c5ad4a2f

15:38:08 - 6ab66a348097277c16a9d57ceefea406

15:38:08 - 30ea8ac97559bed72d41abb6e2bd30c8

15:38:08 - a023cb73e9c26606d8f1c9dd03273fd2

15:38:08 - 832ff060010750a8782834b20ff6334c

15:38:08 - d5dad1ebc02c8930723a2e13be06b4fe

15:38:08 - b84c3ee0613dd4fe48d86e7ef4cc3a25

15:38:08 - debug csc :

15:38:08 - 7ee7c9113724756663bf11fab9e0923b

15:38:08 - 8aeb94495fed5eb53abd55afef8952a9

15:38:08 - 91a8c1f5491ba286876180f3440308c0

15:38:08 - 0535a4098641636f5b8ee2b6d5b24de2

15:38:08 - 65a92687f36f4edace21e8528b82c024

15:38:08 - 42afe5cba6d36bb073ed9444e4320279

15:38:08 - c49774c9cd90115886b899afc371d491

15:38:08 - 2283bd977d325c8a39275e0d41eaf25f

15:38:08 - b4ccd8a3253826b7847a65dfe30b7bcd

15:38:08 - 08799e28ad4b50e5ba88b51611caa8a7

15:38:08 - 9d02afa4885e110f66a2c2d0768b83ef

15:38:08 - cfa26f2f8914e946341e78db3b5f4355

15:38:08 - b753baa4c739890ca794e0789bf09d31

15:38:08 - 9a4fa8d94a594f25ba6412fce3a7c695

15:38:08 - bc23b1f5c1156189fe4ec02ed16394dd

15:38:08 - 798fadf82a313bb429815a423b10ba91

15:38:08 - Alloc(256)

15:38:08 - Alloc(256)

15:38:08 - Ext_ebt_tnpble_init ret : 0

15:38:08 - StackOverflow3:0

15:38:08 -

15:38:08 - make_SIGN_MESSAGE

15:38:08 - StackOverflow3:0

15:38:08 -

15:38:08 - Ext_ebt_tnpble_sign start

15:38:08 - mpi_init end

15:38:08 - free memory : 3268

15:38:08 - Alloc(256)

15:38:08 - mpi_read_binary ok

15:38:08 - mpi_exp_mod start

15:38:08 - Alloc(260)

15:38:08 - Alloc(260)

15:38:08 - Alloc(520)

15:38:08 - Alloc(4)

15:38:08 - Alloc(516)

15:38:08 - Alloc(516)

15:38:08 - Alloc(256)

15:38:08 - Alloc(524)

15:38:08 - Alloc(8)

15:38:08 - Alloc(12)

15:38:08 - Alloc(260)

15:38:08 - Alloc(516)

15:38:08 - Alloc(8)

15:38:08 - Alloc(12)

15:38:08 - Alloc(8)

15:38:08 - Alloc(264)

15:38:08 - Alloc(516)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(260)

15:38:08 - Alloc(260)

15:38:08 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - unable to alloc!!

15:38:09 - 324, -16

15:38:09 -

15:38:09 - sign_message : -16

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09  bd_addr[5:2] = 20 73 7A 10

15:38:09  bd_addr[1:0] = 5A1C 00

15:38:09  GPIO 0001 (11)

15:38:09  GPIO 0000 (104)

15:38:09  GPIO 0014 (1003)

15:38:09  GPIO 0015 (20)

15:38:09  GPIO 0028 (2001)

15:38:09  Interrupt mask[0,1]:0001 0000

15:38:09  Interrupt mask[2]:0000

15:38:09  GPIO_WP:OFF= 00

15:38:09  GPIOBTN1:OFF=1,INT:0

15:38:09  GPIO_LED:OFF=1

15:38:09  GPIOBAT

15:38:09  GPIO_BUZ:OFF=0

15:38:09  BUZBeep(0)

0 Likes
1 Solution
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

Can you try instrumenting the free() function too and see how many are allocated/freed? You are allocating a lot of small buffers, but most will be from the pool of the large buffers. You might want to think about increasing the size of the other buffer pools too (and reduce the larger one - you don't nee so many). Try optimizing your allocation.

View solution in original post

0 Likes
1 Reply
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

Can you try instrumenting the free() function too and see how many are allocated/freed? You are allocating a lot of small buffers, but most will be from the pool of the large buffers. You might want to think about increasing the size of the other buffer pools too (and reduce the larger one - you don't nee so many). Try optimizing your allocation.

0 Likes