Silicon Labs: Add cryptographic acceleration support #4825

stevew817 · 2017-07-28T17:31:40Z

Initial commit of mbed TLS hardware acceleration drivers for Silicon Labs parts

Description

This commit adds HW acceleration drivers for mbed TLS on Silicon Labs parts.

Hardware support:
EFM32ZG/HG/WG/GG/LG:

support for AES-128 and AES-256

EFR32MG1/EFM32PG1:

support for AES-128 and AES-256
support for ECP acceleration on secp192r1, secp224r1 and secp256r1
support for SHA1 and SHA-256

EFR32MG12/EFM32PG12:

two accelerator units available when in threaded mode
support for hardware TRNG
support for AES-128 and AES-256
support for ECP acceleration on secp192r1, secp224r1 and secp256r1
support for SHA1 and SHA-256

Status

READY

Tested with TESTS/mbedtls/* on mbed-os master

+---------------------------+-------------------+------------------------+---------------------------+--------+--------+--------+--------------------+
| target                    | platform_name     | test suite             | test case                 | passed | failed | result | elapsed_time (sec) |
+---------------------------+-------------------+------------------------+---------------------------+--------+--------+--------+--------------------+
| EFM32PG12_STK3402-GCC_ARM | EFM32PG12_STK3402 | tests-mbedtls-multi    | Crypto: sha256_multi      | 1      | 0      | OK     | 0.08               |
| EFM32PG12_STK3402-GCC_ARM | EFM32PG12_STK3402 | tests-mbedtls-multi    | Crypto: sha256_split      | 1      | 0      | OK     | 0.04               |
| EFM32PG12_STK3402-GCC_ARM | EFM32PG12_STK3402 | tests-mbedtls-selftest | mbedtls_entropy_self_test | 1      | 0      | OK     | 0.04               |
| EFM32PG12_STK3402-GCC_ARM | EFM32PG12_STK3402 | tests-mbedtls-selftest | mbedtls_sha256_self_test  | 1      | 0      | OK     | 0.12               |
| EFM32PG12_STK3402-GCC_ARM | EFM32PG12_STK3402 | tests-mbedtls-selftest | mbedtls_sha512_self_test  | 1      | 0      | OK     | 8.27               |
+---------------------------+-------------------+------------------------+---------------------------+--------+--------+--------+--------------------+
mbedgt: test case results: 5 OK

Underlying drivers have been tested on the full mbed TLS test suite
Effect of hardware acceleration with mbed-os-example-tls / benchmark on EFM32PG12, single threaded.

  SHA-256                  :      12871 KB/s
  SHA-512                  :        209 KB/s
  AES-CBC-128              :       4254 KB/s
  AES-CBC-192              :     560329 KB/s
  AES-CBC-256              :       3740 KB/s
  AES-GCM-128              :        210 KB/s
  AES-GCM-192              :     100927 KB/s
  AES-GCM-256              :        208 KB/s
  AES-CCM-128              :        459 KB/s
  AES-CCM-192              :      69031 KB/s
  AES-CCM-256              :        440 KB/s
  CTR_DRBG (NOPR)          :       1497 KB/s
  CTR_DRBG (PR)            :       1008 KB/s
  HMAC_DRBG SHA-256 (NOPR) :        452 KB/s
  HMAC_DRBG SHA-256 (PR)   :        387 KB/s
  RSA-2048                 :      85 ms/ public
  RSA-2048                 :    3253 ms/private
  RSA-4096                 :     287 ms/ public
  RSA-4096                 :   17465 ms/private
  ECDHE-secp384r1          :    2683 ms/handshake
  ECDHE-secp256r1          :      94 ms/handshake
  ECDHE-Curve25519         :    1433 ms/handshake
  ECDH-secp384r1           :    1320 ms/handshake
  ECDH-secp256r1           :      45 ms/handshake
  ECDH-Curve25519          :     741 ms/handshake

DONE

Todos

Tests
Documentation

Deploy notes

None

stevew817 · 2017-07-28T17:35:12Z

CC:
@screamerbg @0xc0170 @yanesca

amq · 2017-07-29T09:25:34Z

Why is AES-192 much faster than AES-128?

upd: I see, it's unsupported (MBEDTLS_ERR_AES_INVALID_KEY_LENGTH)

stevew817 · 2017-07-29T16:15:24Z

@amq Correct. Sadly, the benchmark application doesn't actually check the validity of the operation. That's why one needs to run the mbed OS tests for mbed TLS in addition (though not a bad idea regardless).

theotherjimmy · 2017-07-31T14:59:07Z

@stevew817 The travis errors were resolved in #4839. Could you rebase so that travis can pass?

theotherjimmy · 2017-07-31T15:11:04Z

@stevew817 Thanks for the PR. We use the PR titles in release notes, which are formatted with markdown. The [ and ] characters are markdown syntax for a link, which I don't thin is your intent. Could you replace them with a :?

Initial commit of mbed TLS hardware acceleration drivers for Silicon Labs parts

stevew817 · 2017-08-01T07:30:11Z

@theotherjimmy Rebased and renamed.

theotherjimmy · 2017-08-01T16:49:03Z

Excelent. Let's do some reviewing!

screamerbg · 2017-08-02T09:08:22Z

PR is ready for review @RonEld @yanesca @sbutcher-arm @andresag01

RonEld

This PR is a mixture of several features and topics. It would have been better if this PR was split to several PRs
There are some recurring comments on the critical section, that probably only needs expanation, but there are other comments that need your addressing.
@hanno-arm please review as well

RonEld · 2017-08-02T10:37:10Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_aes.c

+
+#include "em_device.h"
+
+#if defined(CRYPTO_PRESENT)


If this Macro is undefined, you will probably have link error, because you will have undefined functions - the aes functions will not be compiled in mbedtls/src/aes.c because of the MBEDTLS_AES_ALT , and they will not be compiled in this file because of this macro.

MBEDTLS_AES_ALT is only defined when CRYPTO_PRESENT is defined (see mbedtls_device.h)

@stevew817: I think you are correct, but given that the dependency is MBEDTLS_AES_ALT on CRYPTO_PRESENT and not the other way around (as in mbedtls_device.h) I think that this preprocessor check should be around #if defined(MBEDTLS_AES_ALT) and not the other way around. At the moment this is not an issue, but if in the future this changes, then it is much easier to make a mistake...

Looking at mbedtls_device.h I would think that MBEDTLS_AES_ALT is also defined when AES_PRESENT is defined. And if I understand correctly in this caseCRYPTO_PRESENT can't be defined.

Could you please help me understand

why are the contents of crypto_aes.c protected by #if defined(CRYPTO_PRESENT) guards, but the contents of aes_aes.c are not protected by #if defined(AES_PRESENT) macros?

why are mbedtls_aes_decrypt() and mbedtls_aes_encrypt() implemented in aes_aes.c but not in crypto_aes.c?

aes_aes.c is protected by AES_PRESENT (line 28)

mbedtls_aes_encrypt and _decrypt not being present in crypto_aes was an oversight, fixed.

RonEld · 2017-08-02T10:38:59Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_aes.c

+  {
+    uint32_t temp[4];
+    CRYPTO_DataRead(reg, temp);
+    memcpy((void*)val, temp, 16);


it is better to do sizeof(temp) rather than 16.

RonEld · 2017-08-02T10:40:00Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_aes.c

+  if ((uint32_t)val & 0x3)
+  {
+    uint32_t temp[4];
+    memcpy(temp, val, 16);


it is better to do sizeof(temp) rather than 16.
Can you assure that val is of length 16?

Yes. If you look through the usages, all calls to DataWrite/DataRead happen with buffers that are checked to be 16 bytes. They have to, since the Data registers are 128 bits, and don't accept partial reads/writes.

RonEld · 2017-08-02T11:01:44Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_aes.c

+
+    if ( ( 128UL != keybits ) && ( 256UL != keybits ) ) {
+        /* Unsupported key size */
+        return( MBEDTLS_ERR_AES_INVALID_KEY_LENGTH );


Keep in mind that once Mbed-TLS/mbedtls#964 will be approved and merged, this error should probably be changed to MBEDTLS_ERR_AES_FEATURE_UNAVAILABLE for 192 bit size key.
But since the PR is not merged and fully approved, it is not final yet

Considering the PR hasn't made it in, I can't return the new error code in my port...

Of course, this comment was only an FYI, so will know that you will probably need to change this in the future

RonEld · 2017-08-02T11:06:45Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_aes.c

+    device->CMD = CRYPTO_CMD_INSTR_AESENC;
+    while ((device->STATUS & CRYPTO_STATUS_INSTRRUNNING) != 0);
+
+    CORE_ENTER_CRITICAL();


I assume this is a critical section.
What resource are you protecting? Is it device? if yes, then you should protect also the device->WAC = 0 and device->CTRL = 0 a few lines before

The resource we are protecting with critical sections is writing to or reading from 128-bit, 256-bit or 512-bit registers in our accelerator. Since that operation is done with actionable reads/writes from/to a single 32-bit register, they have to be protected against preemption.

The other registers (such as WAC and CTRL) are regular registers, which we get control over by acquiring the device. In the case of preemption, these values will be backed up and put back by the preempting code, so their use is safe.

ok , thanks

RonEld · 2017-08-02T12:37:18Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_sha.c

+    crypto->SEQCTRLB = 0;
+
+    /* Put the state back */
+    CORE_ENTER_CRITICAL();


same comment on the critical section

Same comment as before on the consecutive reads/writes needed to load a full 128-bit value

RonEld · 2017-08-02T12:43:47Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_sha.c

+        size_t blocks = ilen / 64;
+        crypto_sha_update_state( ctx->state, input, blocks, CRYPTO_SHA2 );
+        input += blocks * 64;
+        ilen  -= blocks * 64;


shouldn't ctx->total[0] be decreased with what was processed already?

ctx->total is an upcounter to count the amount of SHA'd bytes, and it is updated with the total amount of data passed to this function (ilen) earlier in this function.

have you tested a use case of Doing twice update of 65 bytes, and then finish?
I think I understand what you did.
Isn't it better to have only one counter, that will only tell the size of the "residue buffer"? Once this "counter" will reach 64, you will call crypto_sha_update_state , and set this residue buffer size to zero

RonEld · 2017-08-02T12:48:08Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_sha.c

+        mbedtls_sha1_process( ctx, ctx->buffer );
+        input += fill;
+        ilen  -= fill;
+        left = 0;


shouldn't ctx->total[0] be decreased with what was processed already?

ctx->total is an upcounter to count the amount of SHA'd bytes, and it is updated with the total amount of data passed to this function (ilen) earlier in this function.

I think I understand what you did.
Isn't it better to have only one counter, that will only tell the size of the "residue buffer"? Once this "counter" will reach 64, you will call crypto_sha_update_state , and set this residue buffer size to zero

RonEld · 2017-08-02T12:52:51Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_sha.c

+ * \param ctx      SHA-1 context
+ * \param output   SHA-1 checksum result
+ */
+void mbedtls_sha1_finish( mbedtls_sha1_context *ctx,


this is very much similar as mbedtls_sha256_finish.
Consider combining the two, when possible

Considering the context struct and output length are different, I don't really see the point of adding yet another function call to the stack for maybe a few bytes of code space gain.

RonEld · 2017-08-02T12:54:42Z

features/mbedtls/targets/TARGET_Silicon_Labs/mbedtls_device.h

+#define MBEDTLS_AES_ALT
+
+#define MBEDTLS_ECP_INTERNAL_ALT
+#define ECP_SHORTWEIERSTRASS


This should not be defined in this file. It's configuration specific

* Use _C flags at compile time in SHA to avoid compiling in unconfigured features * Don't define ECP_SHORTWEIERSTRASS since it is part of the application's configuration

stevew817 · 2017-08-02T14:05:21Z

@RonEld I think I answered all of your questions and committed your feedback.

stevew817 · 2017-08-03T06:53:25Z

@0xc0170 why did uvisor CI fail?

0xc0170 · 2017-08-03T10:18:07Z

retest uvisor

0xc0170 · 2017-08-03T10:18:25Z

@0xc0170 why did uvisor CI fail?

Jenkins error, needs restart

stevew817 · 2017-08-03T11:15:45Z

@0xc0170 Did the retest work? It looks to be still failing...

0xc0170 · 2017-08-03T11:40:54Z

@mazimkhan Can you please restart uvisor? Seems like my last comment did not

stevew817 · 2017-08-07T13:06:36Z

@RonEld did I satisfy your concerns?

RonEld · 2017-08-07T13:56:18Z

@stevew817 I am still not sure why you can't set the key buffer in teh context when you set the key, and when doing the specific cryptographic operation, you set the key in the HW register
Other than that, my questions were answered

stevew817 · 2017-08-07T14:09:58Z

@RonEld This only applies when setting a decryption key. For AES on our parts, the 'key' needs to be pre-processed when you are doing a decryption operation. This pre-processing is what you are seeing in setkey_dec.
See paragraph 27.4.4 (about PlainKey and CipherKey) in https://www.silabs.com/documents/public/reference-manuals/EFR32xG1-ReferenceManual.pdf

RonEld · 2017-08-07T14:20:42Z

@stevew817 Thanks for the reference
According to your reference:" After one decryption, the resulting key will be the PlainKey."
Is the key in the register still Cipherkey?
What I mean is, will the operation:

mbedtls_aes_setkey_dec
mbedtls_aes_crypt_cbc
mbedtls_aes_crypt_cbc

Work, or will you need to load the Cipher key again between every operation?

stevew817 · 2017-08-07T14:34:33Z

@RonEld We don't read back the key register after aes_crypt_cbc, and the next call will put the key from the context in the keybuf register, so the operation you mentioned will work.

RonEld · 2017-08-07T14:36:30Z

OK, thanks

stevew817 · 2017-08-08T12:56:35Z

@RonEld Do I need a review from anyone else?

RonEld · 2017-08-08T12:59:00Z

@stevew817 Yes. I am not hte final gate keeper for mbed TLS

stevew817 · 2017-10-31T17:58:36Z

@adbridge done.

stevew817 · 2017-11-02T00:41:03Z

@adbridge @0xc0170 Anything else keeping this from being merged?

adbridge · 2017-11-06T10:58:55Z

@mazimkhan @hanno-arm please confirm you are happy with the rework

hanno-becker · 2017-11-06T11:04:52Z

@adbridge: @Patater is stepping in for @mazimkhan during his paternity leave. I'll synchronize with @sbutcher-arm to see if this needs a third review with @RonEld's still present from the time before the reshuffling.

hanno-becker · 2017-11-07T15:57:46Z

@adbridge: It was decided by @sbutcher-arm that for this PR, two reviews (by @Patater and @RonEld) are sufficient.

adbridge · 2017-11-07T17:09:02Z

@Patater Could you give this the final once over then please. This has been outstanding for 3 months

0xc0170 · 2017-11-08T13:17:05Z

/morph build

mbed-ci · 2017-11-08T14:12:52Z

Build : SUCCESS

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

Triggering tests

/morph test
/morph uvisor-test

mbed-ci · 2017-11-08T19:01:27Z

Test : SUCCESS

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

Patater

This is looking pretty good to me; it's close. I have a number of questions and style/maintainability suggestions.

In general, the coding style is not consistent in this PR. Please consider using a consistent coding style (preferably Mbed OS style).

Patater · 2017-11-10T09:07:45Z

features/mbedtls/targets/TARGET_Silicon_Labs/aes_aes.c

+            aes_lock();
+            AES_ECB128( output,
+                        input,
+                        16,


Would it be better to use MBEDTLS_AES_BLOCK_SIZE or AES_BLOCKSIZE instead of "16" wherever applicable in this PR? (Might require making a new define in this file)

Considering the 16 byte size is also hardcoded in the function signature, I think it should be fine hardcoding it here as well. The blocksize is never -ever- going to change.

OK.

The main reason for doing this would be readability and not because we'd want to change it in the future.

Patater · 2017-11-10T11:15:20Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_aes.c

+                processed++;
+            }
+
+            crypto_management_release(device);


It's weird that crypto_management_acquire is called inside the else but crypto_management_release is called outside the else. Due to the use of continue in the if body, consider removing the else or moving the crypto_management_release inside the else body.

I think you read the code wrong? _acquire and _release are both at the same level inside the else.

OK.

I now see crypto_management_release is inside the else body.

Patater · 2017-11-10T11:17:31Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_aes.c

+            n = ( n + 1 ) & 0x0F;
+            processed++;
+            continue;
+        } else {


Due to the continue in the if body, consider if this else is really needed.

Similar crypto_management_acquire and crypto_management_release imbalance is here as in mbedtls_aes_crypt_cfb128.

Similar comment here... Are we looking at different versions of the code? I really do see acquire on line 498, which is inside the else and on the same level as the release on line 543.

OK.

I now see crypto_management_release is inside the else body.

Patater · 2017-11-10T11:20:23Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_aes.c

+            for (size_t i = 0; i < iterations; i++ ) {
+                device->CMD = CRYPTO_CMD_INSTR_DATA1TODATA0;
+                device->CMD = CRYPTO_CMD_INSTR_AESENC;
+                while ((device->STATUS & CRYPTO_STATUS_INSTRRUNNING) != 0);


I wish we had a way to avoid these busy loops.

See #5206 to track this issue.

However, even if this was addressed in Mbed OS through, for example, a new Mbed-OS-specific feature, could you make use of it? You mention this code must run on other platforms than Mbed OS, but I'd hate to see potential energy efficiency gains thrown away for the sake of portability.

This might be a future feature best implemented using the mbedTLS threading primitives (if the api would support semaphores in addition to mutexes, since the release would happen from IRQ).

For this specific case, I doubt it would make a whole lot of sense since an AES block operation only takes about 70 clock cycles anyways. Context-switching away and back again would be more expensive. Halting the core might be an alternative.

For efficiency when using accelerators, how about adding an API for multi-block ECB operations? Setting up and tearing down the accelerator for each block is expensive.

Patater · 2017-11-10T11:21:57Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_ecp.c

+#define ECC_BIGINT_SIZE_IN_BITS        (256)
+#define ECC_BIGINT_SIZE_IN_BYTES       (ECC_BIGINT_SIZE_IN_BITS/8)
+#define ECC_BIGINT_SIZE_IN_32BIT_WORDS (ECC_BIGINT_SIZE_IN_BYTES/sizeof(uint32_t))
+#define EC_BIGINT_COPY(X, Y) memcpy(X, Y, sizeof(ecc_bigint_t));


Please place parenthesis around all invoked macro parameters.

- #define EC_BIGINT_COPY(X, Y) memcpy(X, Y, sizeof(ecc_bigint_t)); + #define EC_BIGINT_COPY(X, Y) memcpy((X), (Y), sizeof(ecc_bigint_t));

Patater · 2017-11-10T12:04:46Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_management.h

+ *  limitations under the License.
+ */
+
+#ifndef MBEDTLS_CRYPTO_MANAGEMENT_H


Don't use MBEDTLS prefix here, please.

Patater · 2017-11-10T12:07:12Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_sha.c

+
+    /* Load the data block(s) */
+    for ( size_t i = 0; i < blocks; i++ ) {
+        if ((uint32_t)(&data[i*64]) & 0x3)


Consider making a #define for 64.

Sure. Can I point out that the mbed TLS 'official' software implementation doesn't use a define for SHA blocksize, either? And the blocksize is hardcoded as part of the API?

Patater · 2017-11-10T12:07:55Z

features/mbedtls/targets/TARGET_Silicon_Labs/crypto_sha.c

+
+    if ( is224 != 0 ) {
+        ctx->is224 = true;
+        memcpy(ctx->state, init_state_sha224, 32);


Consider making a #define for 32.

Patater · 2017-11-10T12:14:42Z

targets/targets.json

@@ -2320,7 +2320,7 @@
        "inherits": ["EFM32"],
        "extra_labels_add": ["EFM32GG", "1024K", "SL_AES"],
        "core": "Cortex-M3",
-        "macros": ["EFM32GG990F1024", "TRANSACTION_QUEUE_SIZE_SPI=4"],
+        "macros": ["EFM32GG990F1024", "TRANSACTION_QUEUE_SIZE_SPI=4", "MBEDTLS_CONFIG_HW_SUPPORT"],


Can we put this on EFM32 or do not all EFM32 have hardware support now?

Sure, it can be moved to the EFM32 generic target.

Patater · 2017-11-10T12:15:45Z

targets/targets.json

@@ -2794,7 +2794,7 @@
    },
 	"EFR32MG12P332F1024GL125": {
        "inherits": ["EFM32"],
-        "extra_labels_add": ["EFR32MG12", "1024K", "SL_RAIL", "SL_CRYPTO"],
+        "extra_labels_add": ["EFR32MG12", "1024K", "SL_RAIL", "SL_CRYPTO", "MBEDTLS_CONFIG_HW_SUPPORT"],


Why is MBEDTLS_CONFIG_HW_SUPPORT added to extra_labels_add on this target instead of to macros like on other targets?

Oops. Fixed.

ashok-rao · 2017-11-10T13:04:01Z

@stevew817 FYI, some new comments received. Could you please check?

stevew817 · 2017-11-10T15:01:17Z

@ashok-rao @Patater Will do.

Patater

LGTM

0xc0170 · 2017-11-13T14:58:10Z

Apply feedback by @Patater

The commits looks good but the message does not say much what is it fixing. Can you fix it?

/morph build

mbed-ci · 2017-11-13T15:04:58Z

Build : FAILURE

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

mbed-ci · 2017-11-13T16:32:58Z

Build : SUCCESS

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

Triggering tests

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

theotherjimmy · 2017-11-13T16:41:24Z

/morph test
/morph uvisor-test

mbed-ci · 2017-11-13T18:45:50Z

Exporter Build : SUCCESS

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

mbed-ci · 2017-11-13T19:25:22Z

Test : SUCCESS

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

theotherjimmy added the needs: work label Jul 31, 2017

[Silicon Labs] cryptographic acceleration support

1e51dfa

Initial commit of mbed TLS hardware acceleration drivers for Silicon Labs parts

stevew817 force-pushed the feature/mbedtls-hw-accel branch from 18e0947 to 1e51dfa Compare August 1, 2017 07:26

stevew817 changed the title ~~[Silicon Labs] Add cryptographic acceleration support~~ Silicon Labs: Add cryptographic acceleration support Aug 1, 2017

theotherjimmy added needs: review and removed needs: work labels Aug 1, 2017

RonEld suggested changes Aug 2, 2017

View reviewed changes

Apply feedback from @RonEld

e07ab46

* Use _C flags at compile time in SHA to avoid compiling in unconfigured features * Don't define ECP_SHORTWEIERSTRASS since it is part of the application's configuration

Cosmetic fix

2f02a23

Patater suggested changes Nov 10, 2017

View reviewed changes

Apply feedback by @Patater

1dc3941

Patater approved these changes Nov 13, 2017

View reviewed changes

0xc0170 added needs: CI and removed needs: review labels Nov 13, 2017

0xc0170 added ready for merge release-version: 5.6.5 and removed needs: CI labels Nov 14, 2017

0xc0170 merged commit 3bedff3 into ARMmbed:master Nov 16, 2017

0xc0170 removed the ready for merge label Nov 16, 2017

adbridge pushed a commit that referenced this pull request Nov 17, 2017

Applied @yanesca and @andresag01 comments (#4825)

c5ac3ee

ciarmcom added the closed_in_jira label Dec 1, 2017


		#include "em_device.h"

		#if defined(CRYPTO_PRESENT)

Silicon Labs: Add cryptographic acceleration support #4825

Silicon Labs: Add cryptographic acceleration support #4825

Conversation

stevew817 commented Jul 28, 2017

Description

Status

Todos

Deploy notes

stevew817 commented Jul 28, 2017

amq commented Jul 29, 2017 • edited Loading

stevew817 commented Jul 29, 2017

theotherjimmy commented Jul 31, 2017

theotherjimmy commented Jul 31, 2017

stevew817 commented Aug 1, 2017

theotherjimmy commented Aug 1, 2017 • edited Loading

screamerbg commented Aug 2, 2017

RonEld 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

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

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

stevew817 commented Aug 2, 2017

stevew817 commented Aug 3, 2017

0xc0170 commented Aug 3, 2017

0xc0170 commented Aug 3, 2017

stevew817 commented Aug 3, 2017

0xc0170 commented Aug 3, 2017

stevew817 commented Aug 7, 2017

RonEld commented Aug 7, 2017

stevew817 commented Aug 7, 2017

RonEld commented Aug 7, 2017

stevew817 commented Aug 7, 2017

RonEld commented Aug 7, 2017

stevew817 commented Aug 8, 2017

RonEld commented Aug 8, 2017

stevew817 commented Oct 31, 2017

stevew817 commented Nov 2, 2017

adbridge commented Nov 6, 2017

hanno-becker commented Nov 6, 2017

hanno-becker commented Nov 7, 2017

adbridge commented Nov 7, 2017

0xc0170 commented Nov 8, 2017

mbed-ci commented Nov 8, 2017

Triggering tests

mbed-ci commented Nov 8, 2017

Patater left a comment • 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

Choose a reason for hiding this comment

amq commented Jul 29, 2017 •

edited

Loading

theotherjimmy commented Aug 1, 2017 •

edited

Loading

Patater left a comment •

edited

Loading

stevew817 Nov 11, 2017 •

edited

Loading