Add TRNG for NRF52832 #6116

marcuschangarm · 2018-02-16T06:21:51Z

Use SoftDevice API to get random numbers when present and active,
otherwise read random numbers directly from TRNG peripheral.

ciarmcom · 2018-02-16T12:50:24Z

ARM Internal Ref: IOTSSL-2100

0xc0170 · 2018-02-21T07:44:05Z

Can you please resolve the conflicts?

yogpan01 · 2018-02-21T07:59:03Z

@marcuschangarm This PR may require rebase.

TeroJaasko · 2018-02-21T11:38:29Z

@marcuschangarm I can confirm that this works on my NRF52_DK after rebasing it with current master (to get the SWO support) and resolving the conflict on targets.json.

hanno-becker · 2018-02-21T13:20:55Z

targets/TARGET_NORDIC/TARGET_NRF5/TARGET_SDK11/drivers_nrf/hal/nrf_rng.h

+ *@}
+ **/
+
+#ifndef SUPPRESS_INLINE_IMPLEMENTATION


What is the reason for this macro? Where are the functions defined if it's set?

hanno-becker · 2018-02-21T13:23:30Z

targets/TARGET_NORDIC/TARGET_NRF5/TARGET_SDK11/drivers_nrf/hal/nrf_rng.h

+{
+    *((volatile uint32_t *)((uint8_t *)NRF_RNG + rng_event)) = NRF_RNG_EVENT_CLEAR;
+#if __CORTEX_M == 0x04
+    volatile uint32_t dummy = *((volatile uint32_t *)((uint8_t *)NRF_RNG + rng_event));


What's the significance of this dummy read?

hanno-becker · 2018-02-21T13:29:47Z

targets/TARGET_NORDIC/TARGET_NRF5/trng_api.c

 void trng_free(trng_t *obj)
 {
    (void) obj;
-
-    nrf_drv_rng_uninit();


Why has this been removed even in case SD is enabled?

There is no good way (at least in this version of the SDK) to keep track of SoftDevice state. Imagine a case where trng_init is called before the SoftDevice is enabled and trng_free is called after, then we would have an inconsistent pairing of init/uninit calls.

In this version the TRNG is kept running after the first call. The power consumption for that is orders of magnitude lower than the SoftDevice in sleep mode.

@marcuschangarm Ok, but with the present code, issuing multiple trng_init / trng_free calls leads to failure, which is not consistent with the TRNG API. What about calling nrf_drg_rng_uninit if only if trng_init == false -- i.e. if the TRNG has been initialized when SoftDevice was enabled -- and resetting it to trng_init = true? This way, multiple trng_init / trng_free calls would be fine, as long as it doesn't happen that the SoftDevice gets disabled in the middle of a trng_init / trng_free pair.

issuing multiple trng_init / trng_free calls leads to failure

I don't understand, can you please elaborate? trng_init doesn't do anything after the first successful call and trng_free is empty.

@marcuschangarm There was a misunderstanding on my side, I agree that multiple trng_init calls with SoftDevice enabled are fine, with all but the first one being no-ops.

Regarding the case you described -- SoftDevice being enabled after trng_init was called: Can we use trng_init == false (and perhaps give it a more descriptive name, pointing out that it's about TRNG initialization in the presence of SoftDevice) instead of NRF_HAL_SD_IS_ENABLED() in trng_get_bytes to avoid using SoftDevice functionality without being sure that it is properly initialized?

Can we use trng_init == false (and perhaps give it a more descriptive name, pointing out that it's about TRNG initialization in the presence of SoftDevice) instead of NRF_HAL_SD_IS_ENABLED() in trng_get_bytes to avoid using SoftDevice functionality without being sure that it is properly initialized?

The SoftDevice does its own TRNG initialization. So we might end up in a situation where we use the low-level TRNG API and steal random numbers from the SoftDevice.

~~How about moving nrf_drv_rng_init to trng_get_bytes instead?~~

Edit: I went ahead and moved the initialization call inside get bytes. This is symmetric to the non-driver, raw register get-bytes code path.

int trng_get_bytes(trng_t *obj, uint8_t *output, size_t length, size_t *output_length) { (void) obj; /* Use SDK RNG driver if SoftDevice is enabled. */ if (NRF_HAL_SD_IS_ENABLED() ) { static bool nordic_driver_init = true; if (nordic_driver_init) { nordic_driver_init = false; nrf_drv_rng_init(NULL); }

hanno-becker · 2018-02-21T13:42:47Z

targets/TARGET_NORDIC/TARGET_NRF5/TARGET_SDK11/drivers_nrf/rng/nrf_drv_rng.c

+#include "nrf_sdm.h"
+#include "nrf_soc.h"
+#else
+#include "app_fifo.h"


Where can I find this file? It doesn't seem to be contained in the code base.

@marcuschangarm Is it intended that this file is missing?

Ah, I see what you are saying. SOFTDEVICE_PRESENT must always be defined in the current setup. Removing it will break the code in many places. The ability to remove the SoftDevice will be introduced in the SDK upgrade we are working on.

@marcuschangarm Ok, thanks for clarifying this!

@marcuschangarm I would prefer not to have large parts of this PR depending on a configuration which is known to be broken, though. Wouldn't it make more sense to error out in a single place if SOFTDEVICE_PRESENT is not defined, and adding support for ! SOFTDEVICE_PRESENT in a single go in your SDK upgrade?

Unfortunately, all files in the Nordic SDK have this built in bug! 😒

We are completely re-implementing most of the mbed HAL for the new SDK and reorganizing the directory structure so that we can both change SoftDevices on the fly and even compile without them. This PR is just to get the Cloud client going until we have the new SDK in place.

hanno-becker · 2018-02-21T13:47:09Z

targets/TARGET_NORDIC/TARGET_NRF5/TARGET_SDK11/drivers_nrf/rng/nrf_drv_rng.c

+        uint8_t softdevice_is_enabled;
+        result = sd_softdevice_is_enabled(&softdevice_is_enabled);
+
+        if (softdevice_is_enabled)


It seems to be safer to only take this branch if sd_softdevice_is_enabled has been successful and softdevice_is_enabled is set.

Note this is 3rd party SDK thus should be sent upstream if needed

hanno-becker

Requested clarification on some parts of the code.

marcuschangarm · 2018-02-21T16:38:45Z

@hanno-arm Thank you for the review!

Everything in the TARGET_SDK11 directory is copied directly from Nordic's SDK and traditionally we don't make modifications unless we are fixing bugs.

Also, this is a temporary implementation until the new SDK upgrade arrives.

marcuschangarm · 2018-02-21T19:59:30Z

@yogpan01 @0xc0170 @TeroJaasko

Rebased!

Use SoftDevice API to get random numbers when present and active, otherwise read random numbers directly from TRNG peripheral.

0xc0170 · 2018-02-22T08:23:26Z

/morph build

mbed-ci · 2018-02-22T08:41:16Z

Build : SUCCESS

Build number : 1212
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6116/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

TeroJaasko · 2018-02-22T09:14:35Z

@marcuschangarm the latest version still works with Cloud client.

mbed-ci · 2018-02-22T10:41:28Z

Exporter Build : SUCCESS

Build number : 883
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6116/

0xc0170 · 2018-02-22T11:59:42Z

The review should be only for file (targets/TARGET_NORDIC/TARGET_NRF5/trng_api.c), the rest of files in this PR are coming from 3rd party library (still can be reviewed but should not be changed if it is not a blocker).

hanno-becker · 2018-02-22T13:33:02Z

targets/TARGET_NORDIC/TARGET_NRF5/trng_api.c

+/** Deinitialize the TRNG peripheral
+ *
+ * @param obj The TRNG object
+ */
 void trng_free(trng_t *obj)
 {
    (void) obj;


@marcuschangarm Apologies if this is repeating something we already touched yesterday, but the following is still not clear to me: Why aren't we initializing the TRNG based on the SoftDevice state at the time of the trng_init call, saving this initialization state somewhere within the trng_t struct or in a global variable, and handling trng_get_bytes and trng_init based on it (in particular, not checking whether SoftDevice has been enabled in the meantime). This way, we could correctly setup the SoftDevice / low-level TRNG drivers in trng_init via nrf_drv_rng_init(NULL) resp. nrf_rng_task_trigger(NRF_RNG_TASK_START);, and free them via nrf_drv_rng_uninit resp. nrf_rng_task_trigger(NRF_RNG_TASK_STOP); in trng_free. Is this unacceptable because we cannot guarantee that SoftDevice is enabled before trng_init is called, and we definitely want to use SoftDevice is possible?

The SoftDevice does its own TRNG initialization. So we might end up in a situation where we use the low-level TRNG API and steal random numbers from the SoftDevice.

I didn't yet understand how that could happen in the above approach.

The user application can enable and disable the SoftDevice at any time. Usually this would be done to save power. On the other hand, the TRNG might be called from different parts of the application at times that are not in lock step with the SoftDevice. So the code must be able to handle init and free calls that are not in sync with the SoftDevice state.

The SoftDevice does its own TRNG initialization. So we might end up in a situation where we use the low-level TRNG API and steal random numbers from the SoftDevice.

I believe the SoftDevice is copying the TRNG byte to a buffer on each interrupt. If we read that byte using the low level API before the SoftDevice gets to read it, weird things might happen.

@marcuschangarm

I believe the SoftDevice is copying the TRNG byte to a buffer on each interrupt. If we read that byte using the low level API before the SoftDevice gets to read it, weird things might happen.

Ah, ok, so this might happen even if the SoftDevice's TRNG driver API is not used?

so this might happen even if the SoftDevice's TRNG driver API is not used?

Sorry, I don't understand the question.

I understood you as saying that when SoftDevice is active, the TRNG byte is automatically read by the SoftDevice driver code when ready, even if there is no code explicitly requesting random data through nrf_drv_rng_rand - is that right? So if trng_init would be called before SoftDevice is initialized, then my suggestion for trng_get_bytes would lead to random data being read from the low-level driver that has potentially already been automatically processed by the SoftDevice driver code, even though trng_api.c didn't request that.

when SoftDevice is active, the TRNG byte is automatically read by the SoftDevice driver code when ready, even if there is no code explicitly requesting random data through nrf_drv_rng_rand - is that right?

Yes.

So if trng_init would be called before SoftDevice is initialized, then my suggestion for trng_get_bytes would lead to random data being read from the low-level driver that has potentially already been automatically processed by the SoftDevice driver code, even though trng_api.c didn't request that.

Yes, that is my concern.

@marcuschangarm Thanks for confirming, then I think your solution is the best one. 👍

mbed-ci · 2018-02-22T13:39:34Z

Test : FAILURE

Build number : 1013
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6116/1013

hanno-becker

I don't like that this PR introduces code under ! SOFTDEVICE_PRESENT which is known to be broken.

Leaving that side, I am ok with how trng_api.c multiplexes between the NRF driver implementation in case SoftDevice is present + active, and a hand-crafted direct driver implementation.
As mentioned in the comments, though, I would prefer to do initialization and cleanup of the native driver resp. the SoftDevice driver in trng_init and trng_free, respectively, which is what these functions are intended for.

Given the importance of the PR and the fact that it looks fine from the perspective of functionality and security, the above concerns are no blockers, and I'm ok approving after @yanesca has given his opinion.

marcuschangarm · 2018-02-22T16:03:57Z

@hanno-arm I completely understand where you are coming from! It's an imperfect solution to a bad situation. I would also be uncomfortable adding files that I can't test because the SOFTDEVICE_PRESENT flag isn't working.

For reference, this is how the new implementation in SDK 14.2 looks like: https://github.com/ARMmbed/mbed-os/blob/feature-nrf528xx/targets/TARGET_NORDIC/TARGET_NRF5x/trng_api.c#L49-L79

marcuschangarm · 2018-02-22T16:28:42Z

/morph test

yanesca

I have the same reservations as @hanno-arm, and although I am approving it on account of the deadline, I would like to emphasise that this approval is for the part of the code that does not use the SDK.

hanno-becker

Approving, reinforcing @yanesca's remarks.

cmonr · 2018-02-22T20:35:16Z

/morph build

mbed-ci · 2018-02-22T21:11:06Z

Build : SUCCESS

Build number : 1223
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6116/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

mbed-ci · 2018-02-22T22:58:55Z

Exporter Build : SUCCESS

Build number : 892
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6116/

mbed-ci · 2018-02-23T02:46:03Z

Test : SUCCESS

Build number : 1024
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6116/1024

cmonr · 2018-02-23T03:02:30Z

Waiting for the second Test: SUCCESS to come in. Was pointed out that I jumped the gun in issuing the morph build command, when the morph test queue was really long.

studavekar · 2018-02-26T17:58:59Z

Waiting for the second Test: SUCCESS to come in. Was pointed out that I jumped the gun in issuing the morph build command, when the morph test queue was really long.

we had aborted first morph test #6116 (comment) since a new build #6116 (comment) was triggered.

0xc0170 requested review from mazimkhan and hanno-becker February 16, 2018 09:29

0xc0170 added needs: review tracking component: security labels Feb 16, 2018

ciarmcom added the mirrored label Feb 16, 2018

0xc0170 mentioned this pull request Feb 19, 2018

[feature-nrf528xx] Fix TRNG for NRF52 #6128

Merged

hanno-becker reviewed Feb 21, 2018

View reviewed changes

0xc0170 added needs: work and removed needs: review labels Feb 21, 2018

Add TRNG for NRF52832

9439c19

Use SoftDevice API to get random numbers when present and active, otherwise read random numbers directly from TRNG peripheral.

0xc0170 approved these changes Feb 22, 2018

View reviewed changes

hanno-becker reviewed Feb 22, 2018

View reviewed changes

yanesca approved these changes Feb 22, 2018

View reviewed changes

hanno-becker approved these changes Feb 22, 2018

View reviewed changes

cmonr added needs: CI and removed needs: work labels Feb 22, 2018

cmonr added ready for merge and removed needs: CI labels Feb 23, 2018

cmonr merged commit c9cefcc into ARMmbed:master Feb 26, 2018

cmonr removed the ready for merge label Feb 26, 2018

ciarmcom added the closed_in_jira label Feb 26, 2018

cmonr added the release-version: 5.7.7 label Feb 28, 2018

marcuschangarm deleted the fix_trng_nrf52 branch March 6, 2018 15:03

This was referenced Mar 8, 2018

TRNG support for nRF5x devices #4588

Closed

Random Number Generator support #3045

Closed

Add TRNG for NRF52832 #6116

Add TRNG for NRF52832 #6116

Conversation

marcuschangarm commented Feb 16, 2018

ciarmcom commented Feb 16, 2018

0xc0170 commented Feb 21, 2018

yogpan01 commented Feb 21, 2018

TeroJaasko commented Feb 21, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marcuschangarm Feb 21, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xc0170 Feb 22, 2018 • edited Loading

Choose a reason for hiding this comment

hanno-becker left a comment

Choose a reason for hiding this comment

marcuschangarm commented Feb 21, 2018

marcuschangarm commented Feb 21, 2018

0xc0170 commented Feb 22, 2018

mbed-ci commented Feb 22, 2018

Triggering tests

TeroJaasko commented Feb 22, 2018

mbed-ci commented Feb 22, 2018

0xc0170 commented Feb 22, 2018 • edited Loading

hanno-becker Feb 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hanno-becker Feb 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hanno-becker Feb 22, 2018 • edited Loading

Choose a reason for hiding this comment

mbed-ci commented Feb 22, 2018

hanno-becker left a comment

Choose a reason for hiding this comment

marcuschangarm commented Feb 22, 2018

marcuschangarm commented Feb 22, 2018

yanesca left a comment

Choose a reason for hiding this comment

hanno-becker left a comment

Choose a reason for hiding this comment

cmonr commented Feb 22, 2018

mbed-ci commented Feb 22, 2018

Triggering tests

mbed-ci commented Feb 22, 2018

mbed-ci commented Feb 23, 2018

cmonr commented Feb 23, 2018

studavekar commented Feb 26, 2018 • edited Loading

marcuschangarm Feb 21, 2018 •

edited

Loading

0xc0170 Feb 22, 2018 •

edited

Loading

0xc0170 commented Feb 22, 2018 •

edited

Loading

hanno-becker Feb 22, 2018 •

edited

Loading

hanno-becker Feb 22, 2018 •

edited

Loading

hanno-becker Feb 22, 2018 •

edited

Loading

studavekar commented Feb 26, 2018 •

edited

Loading