nRF52840: Cryptocell does not work when initialized multiple times

[AGlass0fMilk]

Description of defect

When using mbedTLS with Cryptocell310 on the nRF52840 several libraries interact with mbedTLS to perform various cryptographic functions such as generate random numbers.

I am running such a program, which you can find and compile here for the EP_AGORA target.

When the Azure SDK library attempts to generate a random sequence of bytes using mbedTLS, the program gets infinitely stuck in the call to LLF_RND_GetTrngsource. This is similar to the problem described in #7069.

@pan-

Target(s) affected by this defect ?

nRF52840_DK and any variants of it

Toolchain(s) (name and version) displaying this defect ?

GCC ARM

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

What version of Mbed-os are you using (tag or sha) ?

0db72d0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Package            Version
------------------ -----------
appdirs            1.4.3
asn1ate            0.6.0
attrs              19.3.0
beautifulsoup4     4.6.3
cbor               1.0.0
certifi            2019.11.28
cffi               1.14.1
chardet            3.0.4
Click              7.0
cmsis-pack-manager 0.2.10
cobs               1.1.4
colorama           0.3.9
crc16              0.1.1
crccheck           0.6
cryptography       2.9.2
cycler             0.10.0
ecdsa              0.15
elftools           0.1.0.dev0
fasteners          0.15
future             0.16.0
futures            3.1.1
fuzzywuzzy         0.18.0
hidapi             0.9.0.post2
icetea             1.2.4
idna               2.7
imgtool            1.6.0
importlib-metadata 1.6.0
intelhex           2.2.1
Jinja2             2.10.3
jsonmerge          1.7.0
jsonschema         2.6.0
junit-xml          1.8
kiwisolver         1.2.0
lockfile           0.12.2
Logbook            1.5.3
manifest-tool      1.5.2
MarkupSafe         1.1.1
matplotlib         3.3.0
mbed-cli           1.10.4
mbed-cloud-sdk     2.0.8
mbed-flasher       0.10.1
mbed-greentea      1.7.4
mbed-host-tests    1.5.10
mbed-ls            1.7.12
mbed-os-tools      0.0.15
milksnake          0.1.5
monotonic          1.5
numpy              1.19.1
Pillow             7.2.0
pip                20.2
pkg-resources      0.0.0
prettytable        0.7.2
protobuf           3.5.2.post1
psutil             5.6.6
pyasn1             0.2.3
pycparser          2.20
pycryptodome       3.9.8
pyelftools         0.25
pyparsing          2.4.7
pyrsistent         0.16.0
pyserial           3.4
python-dateutil    2.8.1
python-dotenv      0.14.0
pyusb              1.0.2
PyYAML             4.2b1
requests           2.20.1
semver             2.10.2
setuptools         46.1.3
six                1.12.0
soupsieve          2.0
trollius           2.1.post2
urllib3            1.24.2
wheel              0.34.2
yattag             1.13.2
zipp               3.1.0

How is this defect reproduced ?

Attemp to use mbedTLS to generate random numbers with Cryptocell310 enabled on an nRF52840-based target after initializing/deinitializing with several different library modules.

See example program here:
https://github.com/EmbeddedPlanet/mbed-os-example-for-azure/tree/add-ep-agora

[0xc0170]

cc @ARMmbed/mbed-os-pan

[pan-]

@AGlass0fMilk Thanks for raising this issue. It looks like the function mbedtls_platform_setup is not called by the Azure SDK port. Therefore, the Crypto cell is not properly initialized.
@LDong-Arm Can you look into that ?

[LDong-Arm]

@AGlass0fMilk Thanks for raising this issue. It looks like the function mbedtls_platform_setup is not called by the Azure SDK port. Therefore, the Crypto cell is not properly initialized.
@LDong-Arm Can you look into that ?

We just used the default mbedtls support by Microsoft without any changes. Will look into it. The AWS SDK didn't call mbedtls_platform_setup either and had no issues - maybe different sets of functionalities were used.
A challenge is we don't have an EP_AGORE to test while working from home, and the normal NRF52840_DK has no cellular.

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2317

[ciarmcom]

We closed this issue because it has been inactive for quite some time and we believe it to be low priority. If you think that the priority should be higher, then please reopen with your justification for increasing the priority.