Add reference counter for platform context #7099

RonEld · 2018-06-04T07:39:59Z

Description

Move the mbedtls_platform_context to be platform code, in features/mbedtls/platfrom/.
Add static refernce counter, to setup and teardown the platform code only once.
Adjust Cryptocell porting accordingly.

Should work with system modules using Mbed TLS, such as BLE, that wouldn't terminate the cryptographic driver for the application, in the middle of operation.
Adresses first part of #7069

CC @sbutcher-arm @Patater @pan-

Question: Should we protect the reference counter with a mutex?

Pull request type

[x] Fix
[ ] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change

1. Move the `mbedtls_platform_context` to be platform code, in `features/mbedtls/platfrom/`. 2. Add static refernce counter, to setup and teardown the platform code only once. 3. Adjust Cryptocell porting accordingly.

pan-

Hi Ron,

Thanks for this submission that intend to solves #7069. Unfortunately reference
counting is not the right tool to solve the issue; not at the mbed tls level.

Reference counting implies that a single instance/context is shared across multiple
parts of the program. In our case, it is expected that application code using mbed
tls submit a different/specific context every time mbedtls_platform_setup is
called.

With the code as it is proposed, a context will never be initialized if their is at least
another context initialized. This can have dramatic consequences if crypto_platform_ctx
actually contains valuable informations like CRYS_RND_State_t: The code may setup one
instance and teardown one that hasn't been initialized.

I strongly believe that keeping track of initialization is an implementation detail
and this as no place in the platform code at mbed tls level.

simonbutcher

I think we need to consider the interface changes carefully before we make this change.

cc: @Patater

simonbutcher · 2018-06-04T08:34:10Z

features/mbedtls/platform/src/platform_alt.c

+{
+ int ret = 0;
+ if( ctx == NULL )
+ return ( -1 );


I don't think we should be returning -1, however, we have failed to define in Mbed TLS any error codes for function.

Maybe we should define error codes now locally in Mbed OS, and upstream them to Mbed TLS in time for the following release of Mbed OS? Possibly INVALID_INPUT for the case above, and HW_FAILURE in case of failure from the accelerator. What do you think?

I agree, but as you said, there is currently no error codes available

You could define some locally in Mbed OS, and also submit a PR to upstream the same codes.

As and when the version of Mbed TLS with the new codes becomes available, we can remove the local definitions.

We control both sides (upstream and downstream) so there's no risk of reusing the same values.

I created Mbed-TLS/mbedtls#1993 to add the platform error code

simonbutcher · 2018-06-04T08:48:38Z

features/mbedtls/platform/src/platform_alt.c

+ if( reference_count == 1 )
+ {
+ /* call platform specific code to setup crypto driver*/
+ ret = crypto_platform_setup( &ctx->platform_impl_ctx );


This makes crypto_platform_setup() part of the API for crypto drivers. That will need documenting in the Mbed OS Porting Guide, and also as an interface change will need wider review.

Is there anyway of avoiding this interface change? I'm not sure there is, but we should consider alternatives if we can.

I agree it needs documenting in the handbook.

As for interface change, it's basically only a change in the existing name of the function ( cc_platform_setup renamed to crypto+platform_setup, and a bit of who is responsible of implementing CC initialization has changed). Although it is an API change, I believe it is a minor one
Unfortunately, I don't see any other way to have initialization of the platform, in an opaque way, and make it portable to other APIs. ( we can have the whole mbedtls_platform_setup() functino implemented in driver code, but then we guideusers to implement the reference count , which is very common to all the drivers )

simonbutcher · 2018-06-04T08:51:34Z

features/mbedtls/platform/src/platform_alt.c

+ if( ctx == NULL )
+ return;
+
+ if( reference_count == 0 )


I don't think you need two if statements, and it looks a bit odd.

Have you considered using a less than operator? eg.

reference_count--; if( reference_count <= 0 ) { crypto_platform_teardown(); }

I agree it looks a bit odd, but what you are suggesting is prone to errors:

crypto_platform_teardown() might be called twice, if reference_count is 0 or -1.

corner cases where we get the reference counter to -2, and then when some chooses to setup, it won't initialize the platform, because the counter will be increased to -1.

Perhaps assigning reference_count to 0 after calling crypto_platform_teardown()?

I agree, it would be safer to reassign reference_count.

So...

reference_count--; if( reference_count <= 0 ) { crypto_platform_teardown(); reference_count = 0; }

RonEld · 2018-06-04T08:59:11Z

@pan- The idea in the mbedtls layer, is the platform itslef is shared across all the modules.
It's basically telling: " start cryptography operations" and "stop cryptography operations".

Specifically for NRF53840, there shouldn't be a problem, as the driver is initialized once, and terminated once. The CRYS_RND_State_t holds the trng data for seeding the DRBG. It is used in the CC initialization because the API requires it, but in actual usage, this struct is used in the trng function, for gathering the entropy.

I agree there might be a need for additional tweaking, such as protecting the CRYS_RND_State_t in trng_api.c with a mutex, and protecting the reference coutner with a mutex, or maybe additional changes, but I think it could be postponed,

pan- · 2018-06-04T09:15:31Z

The idea in the mbedtls layer, is the platform itslef is shared across all the modules.

Thanks for the clarification.

In that case wouldn't it make sense to remove crypto_platform_ctx from mbedtls_platform_context and declare a single instance of crypto_platform_ctx alongside reference_count ? That instance would be the only one passed to crypto_platform_setup and crypto_platform_teardown. It would prevent calling teardown on an uninitialized crypto_platform_ctx.

simonbutcher · 2018-06-04T09:16:53Z

Hi @pan-

That's not really how we intended the platform context to be used. It's not well documented, mainly because no one has provided an implementation until now, but the context is supposed to be a one-per-platform singleton.

The intention was you should initialise once.

The implication of what you're suggesting is that the API we're providing isn't adequate, and you actually need a mbedtls_platform_setup(), that takes no context as parameter (as you can't track them), and possibly returns one instead?

1. Add error codes for platform setup \ teardown. 2. Reassign `reference_count` to 0 after terminating platform, and remove condition for 0

RonEld · 2018-06-04T11:04:29Z

@sbutcher-arm I addressed your comments

pan- · 2018-06-04T13:33:21Z

Hi @sbutcher-arm

I agree that if the context passed into mbedtls_platform_setup and mbedtls_platform_teardown is a singleton then reference counting is an adequate solution. Thanks for the clarification.

Given that in the current design the platform context singleton lives outside mbed tls platform layer; library and system code API using mbed tls must be updated to accept the platform context singleton instantiated by the application. In some cases - like BLE - that would force us to expose implementation details that are target specific in our abstract interfaces.

I wonder if it wouldn't be easier to encapsulate the platform context singleton into mbed tls platform layer and completely hide its existence and management from the API exposed to applications. In other words remove the context parameter in setup and teardown.

What do you think ?

PS: If the context is a singleton it may be better to add a reference counter field in the platform context structure rather than having another singleton in the global scope.

0xc0170 · 2018-06-08T12:21:58Z

@RonEld What is the status of this PR? Are there any outstanding issues to be resolved (the changes requested in the review for instance) ?

RonEld · 2018-06-10T07:31:10Z

@0xc0170 I have addressed all the issues. The current status is that there is an architectural decision on how the API should actually look.
I can't really do much until the decision will be made.

cmonr · 2018-06-18T23:25:16Z

@pan- @sbutcher-arm @RonEld Are there conversations happening offline somewhere, or has discussion on this PR simply become stale?

cmonr · 2018-06-29T02:42:27Z

Since no progress has been made on this PR for over two weeks, and there's no sign of external conversations, I'm going to close this PR.

Once updates are available, it can be opened.

Make the platform context a global variable, adding the refernce counter to it.

RonEld · 2018-08-28T17:35:22Z

@cmonr I have available update for this PR. Do you want me to create a new PR or should this one be opened?

cmonr · 2018-08-28T18:10:09Z

@RonEld You can commit it to this PR and it can be reopened.

RonEld · 2018-08-29T08:31:58Z

@pan- I have updated the context to be a global one, holding the reference counter within. You can now call the mbedtls_platform_setup() and mbedtls_platform_teardown() with a NULL argument, as it's being ignored for Mbed OS now.
Note I haven't made it exactly a singleton ( not static ), as it needs to be accessed by other modules. For example, by the trng module, in cryptocell.
Does this fit your needs?

RonEld · 2018-08-29T13:15:51Z

cc @sbutcher-arm @Patater

1. Rename error codes to fit Mbed TLS error code names. 2. Remove the Invalid input error code, as it's not used anymore.

RonEld · 2018-08-30T15:13:51Z

@0xc0170

currently 5.10 PR in the queue

To my understanding, this PR is targeting 5.10

simonbutcher

Minor comments only. My only real concern is your use of the word 'blocker' which I think is misleading.

simonbutcher · 2018-08-29T13:18:45Z

features/mbedtls/platform/src/platform_alt.c

-
-
-int mbedtls_platform_setup( mbedtls_platform_context *ctx )
+int mbedtls_platform_setup( mbedtls_platform_context *obsolete_ctx )


Why is the context called obsolete? I think that's misleading. It's simply unused.

It's obsolete, because it's not used and ignored anymore. I can rename

If it were obsolete it would no longer be used in any context - but that's not true. We're just choosing not to use it in Mbed OS. It could be used in other OS's and platforms.

I really think it's misleading still. Thanks for changing it.

simonbutcher · 2018-08-29T13:20:50Z

features/mbedtls/platform/src/platform_alt.c

-
-
-int mbedtls_platform_setup( mbedtls_platform_context *ctx )
+int mbedtls_platform_setup( mbedtls_platform_context *obsolete_ctx )


Should we check obsolete_ctx is NULL?

I don't think so, it is just being ignored. This way, it will be backwards compatible to applications \ modules using this function, that are still sending a content as parameter. Note the example applications weren't updated yet with NULL as parameter

simonbutcher · 2018-08-29T13:24:56Z

features/cryptocell/FEATURE_CRYPTOCELL310/trng.c


-extern CRYS_RND_State_t rndState;
-extern CRYS_RND_WorkBuff_t rndWorkBuff;
+extern mbedtls_platform_context ctx;


Is this still needed?

yes. Since there isn't any getter function for the context, we still need access to members of it. The RNG functions need the rndState, which is now member of the context

RonEld · 2018-08-31T10:39:01Z

@sbutcher-arm Thank you for your comments. Please refer me to where I use the word "blocker" so i will rephrase.

Rename `obsolete_ctx` to `unused_ctx` as it is simply unused.

RonEld · 2018-08-31T10:56:19Z

@sbutcher-arm i renamed the parameter name to unused_ctx

0xc0170 · 2018-09-02T05:33:48Z

/morph build

mbed-ci · 2018-09-02T07:23:34Z

Build : FAILURE

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

IAR fails to build when a variable is initialized with empty curly braces. Added `{ { 0 } }` to fix that.

RonEld · 2018-09-02T08:28:41Z

build failure on IAR was fixed

NirSonnenschein · 2018-09-02T09:54:20Z

/morph build

mbed-ci · 2018-09-02T11:02:28Z

Build : SUCCESS

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

Triggering tests

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

mbed-ci · 2018-09-02T13:12:16Z

Test : SUCCESS

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

mbed-ci · 2018-09-02T14:42:32Z

Exporter Build : SUCCESS

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

0xc0170 · 2018-09-02T18:22:13Z

Waiting for the last approval from @sbutcher-arm

Add reference counter for platform context

ca94a49

1. Move the `mbedtls_platform_context` to be platform code, in `features/mbedtls/platfrom/`. 2. Add static refernce counter, to setup and teardown the platform code only once. 3. Adjust Cryptocell porting accordingly.

RonEld mentioned this pull request Jun 4, 2018

Cryptocell 310 doesn't work on NRF52840_DK #7069

Closed

0xc0170 added the needs: review label Jun 4, 2018

0xc0170 requested review from a team, Patater and pan- June 4, 2018 08:03

pan- requested changes Jun 4, 2018

View reviewed changes

simonbutcher reviewed Jun 4, 2018

View reviewed changes

Add Mbed TLS Platform module errors

c3b31bc

1. Add error codes for platform setup \ teardown. 2. Reassign `reference_count` to 0 after terminating platform, and remove condition for 0

cmonr closed this Jun 29, 2018

0xc0170 removed the needs: review label Jun 29, 2018

Make the platform context a global variable

127b68f

Make the platform context a global variable, adding the refernce counter to it.

cmonr reopened this Aug 28, 2018

cmonr added the needs: work label Aug 28, 2018

pan- approved these changes Aug 29, 2018

View reviewed changes

RonEld mentioned this pull request Aug 29, 2018

Add platform error codes Mbed-TLS/mbedtls#1993

Merged

Rename error codes

4794389

1. Rename error codes to fit Mbed TLS error code names. 2. Remove the Invalid input error code, as it's not used anymore.

0xc0170 added the release-version: 5.10.0-rc1 label Aug 30, 2018

0xc0170 approved these changes Aug 30, 2018

View reviewed changes

cmonr added needs: CI and removed needs: review labels Aug 30, 2018

simonbutcher suggested changes Aug 31, 2018

View reviewed changes

Rename parameter name

c1b6fdc

Rename `obsolete_ctx` to `unused_ctx` as it is simply unused.

Patater approved these changes Aug 31, 2018

View reviewed changes

Fix build error on IAR

a2531b5

IAR fails to build when a variable is initialized with empty curly braces. Added `{ { 0 } }` to fix that.

NirSonnenschein added ready for merge and removed needs: CI labels Sep 2, 2018

0xc0170 added needs: review and removed ready for merge labels Sep 2, 2018

simonbutcher approved these changes Sep 2, 2018

View reviewed changes

cmonr merged commit 3be076c into ARMmbed:master Sep 3, 2018

0xc0170 removed the needs: review label Sep 3, 2018

This was referenced Sep 3, 2018

Change mbedtls_platform_context parameter to NULL #7960

Merged

Change mbedtls_platform_context parameter to NULL ARMmbed/mbed-os-example-tls#199

Merged

RonEld mentioned this pull request Jan 27, 2019

Initialize platform in trng test #9493

Merged

trowbridgec mentioned this pull request Mar 1, 2019

SecureStore and Cell with nRF52840 #9880

Closed



		int mbedtls_platform_setup( mbedtls_platform_context *ctx )
		int mbedtls_platform_setup( mbedtls_platform_context *obsolete_ctx )

Add reference counter for platform context #7099

Add reference counter for platform context #7099

Conversation

RonEld commented Jun 4, 2018 • edited Loading

Description

Pull request type

pan- left a comment • edited Loading

Choose a reason for hiding this comment

simonbutcher left a 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RonEld commented Jun 4, 2018

pan- commented Jun 4, 2018 • edited Loading

simonbutcher commented Jun 4, 2018

RonEld commented Jun 4, 2018 • edited Loading

pan- commented Jun 4, 2018

0xc0170 commented Jun 8, 2018

RonEld commented Jun 10, 2018

cmonr commented Jun 18, 2018

cmonr commented Jun 29, 2018

RonEld commented Aug 28, 2018

cmonr commented Aug 28, 2018

RonEld commented Aug 29, 2018

RonEld commented Aug 29, 2018

RonEld commented Aug 30, 2018

simonbutcher left a 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

RonEld Aug 31, 2018 • edited Loading

Choose a reason for hiding this comment

RonEld commented Aug 31, 2018

RonEld commented Aug 31, 2018

0xc0170 commented Sep 2, 2018

mbed-ci commented Sep 2, 2018

RonEld commented Sep 2, 2018

NirSonnenschein commented Sep 2, 2018

mbed-ci commented Sep 2, 2018

Triggering tests

mbed-ci commented Sep 2, 2018

mbed-ci commented Sep 2, 2018

0xc0170 commented Sep 2, 2018

RonEld commented Jun 4, 2018 •

edited

Loading

pan- left a comment •

edited

Loading

pan- commented Jun 4, 2018 •

edited

Loading

RonEld commented Jun 4, 2018 •

edited

Loading

RonEld Aug 31, 2018 •

edited

Loading