Two issues with CC310 HW CryptoCell: Linking and hanging

[jakkra]

Hi, we stumbled into two issues when we enabled LESC in our application.

Relevant SDK config:

NRF_CRYPTO_ENABLED

NRF_CRYPTO_BACKEND_CC310_ENABLED

NRF_CRYPTO_BACKEND_CC310_RNG_ENABLED

First one is that pm_init() will hang if called when NRF_CRYPTO_BACKEND_CC310_RNG_ENABLED unless we call sd_nvic_critical_region_enter before and then sd_nvic_critical_region_exit after. I can't find anything documentation saying that we need to do that. See attached stacktrace when calling pm_init() without entering critical region. It's the CRYS_RndInit() which hangs and causes the WD to reset.

Second issue I think is related to linking. 

I have a theory that the linker does not link cc310_backend_init.o file as the two public functions void cc310_backend_enable(void); and void cc310_backend_disable(void); are
found in cc310_backend_shared.c and therefore CRYPTO_BACKEND_REGISTER does not
place cc310_backend_init and cc310_backend_uninit in the crypto_data section in flash.

Causing that cc310_backend_init() is never called when initiating as it's not found in the.crypto_data 

If I add a dummy function to cc310_backend_init.c the two functions are placed in the .crypto_data section in the flash. See the attached patch.txt file.

Fullscreen patch.txt Download

diff --git a/bsp/nRF5_SDK_15.2.0_9412b96/components/libraries/crypto/backend/cc310/cc310_backend_init.c b/bsp/nRF5_SDK_15.2.0_9412b96/components/libraries/crypto/backend/cc310/cc310_backend_init.c
index e3e77f0b..05f29edb 100644
--- a/bsp/nRF5_SDK_15.2.0_9412b96/components/libraries/crypto/backend/cc310/cc310_backend_init.c
+++ b/bsp/nRF5_SDK_15.2.0_9412b96/components/libraries/crypto/backend/cc310/cc310_backend_init.c
@@ -57,6 +57,18 @@ void cc310_backend_enable(void);
  */
 void cc310_backend_disable(void);
 
+// patch start
+uint32_t forceLinkingcc310BackendInit()
+{
+    /*
+    The linker does not link this file as the above two functions are found in cc310_backend_shared.c
+    And therefore CRYPTO_BACKEND_REGISTER does not place cc310_backend_init cc310_backend_uninit 
+    in the crypto_data section in flash. This is a workaround for not ignoring this file.
+    */
+    return 0;
+}
+//patch end
+
 static uint32_t init_result_get(uint32_t crys_error)
 {
     uint32_t ret_val = NRF_ERROR_INTERNAL;
     
--- a/bsp/nRF5_SDK_15.2.0_9412b96/components/libraries/crypto/nrf_crypto_init.c
+++ b/bsp/nRF5_SDK_15.2.0_9412b96/components/libraries/crypto/nrf_crypto_init.c
@@ -79,6 +79,11 @@ ret_code_t nrf_crypto_init(void)
             return ret_val;
         }
     }
+    // patch start
+#if NRF_MODULE_ENABLED(NRF_CRYPTO_BACKEND_CC310)
+    forceLinkingcc310BackendInit();
+#endif
+    // patch end
 
     // Set nrf_crypto to initialized
     m_state = INITIALIZED;
diff --git a/bsp/nRF5_SDK_15.2.0_9412b96/components/libraries/crypto/nrf_crypto_init.h b/bsp/nRF5_SDK_15.2.0_9412b96/components/libraries/crypto/nrf_crypto_init.h
index 8e10ae13..a90125b0 100644
--- a/bsp/nRF5_SDK_15.2.0_9412b96/components/libraries/crypto/nrf_crypto_init.h
+++ b/bsp/nRF5_SDK_15.2.0_9412b96/components/libraries/crypto/nrf_crypto_init.h
@@ -136,6 +136,10 @@ bool nrf_crypto_is_initialized(void);
  */
 bool nrf_crypto_is_initializing(void);
 
+// patch start
+uint32_t forceLinkingcc310BackendInit();
+// patch end
+
 #ifdef __cplusplus
 }
 #endif

SoftDevice: s140_nrf52_6.1.0

SDK: nRF5_SDK_15.2.0_9412b96

[Einar Thorsrud]

Hi,

1. I do not recall seeing this issue before, nor do I immediately understand what is going on. You cannot use CC310 concurrently, and therefore the backed wrapper (cc310_backend_rng.c) use the CC310 mutex. I do not see any reason for using critical sections, though. Therefore, I have a few questions just to understand more about the situation:

• How do you handle memory for the RNG module?
• Is NRF_CRYPTO_RNG_STATIC_MEMORY_BUFFERS_ENABLED set to 1 in the projects sdk_config.h?
• Since using critical sections seem to help - what do you expect is interrupting when initializing the RNG?
• Can you provide an example project that demonstrate this?

2. This is also new to me, so I have a few questions here as well:

• Which toolchain do you use?
• Does it depend on optimization level or other settings?
• Can you provide an example project that demonstrate this?

[evanperrygrove]

I hate to revive a dead thread, but I was having a very similar problem while migrating a project from SDK 15.0 to 15.3. My code was hanging on a DMB instruction somewhere inside SaSi_AesInit. Eventually, the watchdog timed out and the sensor would reboot.

I realized that my sdk_config.h was missing a #define for NRF_CRYPTO_BACKEND_CC310_INTERRUPTS_ENABLED. As soon as I added this (and set it to 1), the problem went away. This appears to be a new macro that was introduced in 15.3 (I did not see it in a quick search of some example code from 15.2).

I also applied jakkra's patch, just to be safe.

Now I'm dealing with a different crash, but the new one doesn't appear to be related to CC310