benchmark example does not finish correctly in NCS36510 dev board

[andresag01]

The benchmark example is very slow to run in the NCS36510 target. Furthermore, after waiting for sometime it does not seem to progress from the CTR_DRBG (PR) when compiled with ARMCC:

  SHA-256                  :        407 Kb/s,         77 cycles/byte
  SHA-512                  :        176 Kb/s,        178 cycles/byte
  AES-CBC-128              :        346 Kb/s,         90 cycles/byte
  AES-CBC-192              :        301 Kb/s,        104 cycles/byte
  AES-CBC-256              :        267 Kb/s,        117 cycles/byte
  AES-GCM-128              :        146 Kb/s,        216 cycles/byte
  AES-GCM-192              :        137 Kb/s,        229 cycles/byte
  AES-GCM-256              :        130 Kb/s,        243 cycles/byte
  AES-CCM-128              :        155 Kb/s,        203 cycles/byte
  AES-CCM-192              :        136 Kb/s,        231 cycles/byte
  AES-CCM-256              :        122 Kb/s,        259 cycles/byte
  CTR_DRBG (NOPR)          :        265 Kb/s,        118 cycles/byte
  CTR_DRBG (PR)            :        192 Kb/s,        163 cycles/byte

When compiled with gcc, the program terminates, but the following error is printed:

  SHA-256                  :        416 Kb/s,         75 cycles/byte
  SHA-512                  :        136 Kb/s,        231 cycles/byte
  AES-CBC-128              :        318 Kb/s,         98 cycles/byte
  AES-CBC-192              :        277 Kb/s,        113 cycles/byte
  AES-CBC-256              :        245 Kb/s,        128 cycles/byte
  AES-GCM-128              :        108 Kb/s,        292 cycles/byte
  AES-GCM-192              :        103 Kb/s,        307 cycles/byte
  AES-GCM-256              :         99 Kb/s,        321 cycles/byte
  AES-CCM-128              :        139 Kb/s,        227 cycles/byte
  AES-CCM-192              :        123 Kb/s,        257 cycles/byte
  AES-CCM-256              :        110 Kb/s,        287 cycles/byte
  CTR_DRBG (NOPR)          :        258 Kb/s,        121 cycles/byte
  CTR_DRBG (PR)            :        185 Kb/s,        170 cycles/byte
  HMAC_DRBG SHA-256 (NOPR) :         50 Kb/s,        649 cycles/byte
  HMAC_DRBG SHA-256 (PR)   :         44 Kb/s,        739 cycles/byte
  RSA-2048                 :     171 ms/ public
  RSA-2048                 :    5566 ms/private
  RSA-4096                 :     595 ms/ public
  RSA-4096                 :  FAILED: RSA - The private key operation failed : BIGNUM - Memory allocation failed
  ECDHE-secp384r1          :    4532 ms/handshake
  ECDHE-secp256r1          :    2722 ms/handshake
  ECDHE-Curve25519         :    2299 ms/handshake
  ECDH-secp384r1           :    2230 ms/handshake
  ECDH-secp256r1           :    1338 ms/handshake
  ECDH-Curve25519          :    1162 ms/handshake

DONE

[0xc0170]

cc @radhika-raghavendran

[yanesca]

The example does not finish correctly when compiled in the online IDE either.

[pradeep-gr]

@0xc0170 Please let me know how to re produce the issue.

[andresag01]

@pradeep-gr: To reproduce the issue checkout the mbed-os-example-tls version tagged with mbed-os-5.3.0-rc1. Then compile using mbed-cli:

mbed compile -t GCC_ARM -m NCS36510

Finally, flash the board and observe the output in the serial terminal. This README describes the expected behaviour.

[andresag01]

It seems that the problem with the toolchains GCC and IAR is that the program eventually runs out of heap memory when trying to grow one of the MPI numbers for 4096 RSA private key calculations.

[ciarmcom]

ARM Internal Ref: IOTSSL-1110

[pradeep-gr]

@andresag01 Not able to build mbed-os-5.3.0-rc1 with mbed-os. main.cpp from mbed-os-example-tls requires EthernetInterface.h file in turn requires target specific lwipopts_conf.h file. But Ethernet interface not available in target NCS36510.

[andresag01]

@pradeep-gr: The error occurs because building from the root of the mbed-os-example-tls project causes mbed-cli to build every project subdirectory. This fails because the tls-client requires a Ethernet interface that the NCS36510 does not support. To build only the benchmark application (the one discussed in this issue), please use the following commands:

git clone git@github.com:ARMmbed/mbed-os-example-tls.git
cd mbed-os-example-tls/benchmark
git checkout mbed-os-5.3.0-rc1       ## This is already setup to pull mbed-os-5.3.0-rc1 version.
mbed compile -t GCC_ARM -m NCS36510
## Flash target and observe serial output.

[pradeep-gr]

@andresag01 Thanks for the details. I am able to re-produce the issue. But I am seeing the same behavior and delay, even if I comment out all the code from trng_init(), trng_free() and trng_get_bytes() functions and just return success. I am also getting below warning "Object file test_env.o is not unique! It could be made from:" on compile even build is successful.

[andresag01]

@sbutcher-arm: As discussed, this is caused either by stack overflow or heap allocation failure (depending on the toolchain used). In some sense, this is a duplicate of #14. Should we close it?

[pradeep-gr]

Command "mbed compile -t GCC_ARM -m NCS36510" successfully builds even when definition of "mbedtls_hardware_poll()" function is removed. I don't think mbed-os-example-tls having any dependency on HAL layer, espaecially on "mbedtls_hardware_poll()" function

[pradeep-gr]

@andresag01 And about the delay: If you compare K64F results (attached below) with NCS36510. As K64F can go up to 120 MHZ where NCC36510 is 32MHz. In this sense timings for NCS36510 are seems to be fine.

[simonbutcher]

Fixed by PR #194 which has now been merged. Issue can be closed.