New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Silicon Labs: Add cryptographic acceleration support #4825

Merged
merged 5 commits into from Nov 16, 2017

Conversation

@stevew817
Contributor

stevew817 commented Jul 28, 2017

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

This comment has been minimized.

Contributor

stevew817 commented Jul 28, 2017

@amq

This comment has been minimized.

Contributor

amq commented Jul 29, 2017

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

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

@stevew817

This comment has been minimized.

Contributor

stevew817 commented Jul 29, 2017

@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

This comment has been minimized.

Contributor

theotherjimmy commented Jul 31, 2017

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

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Jul 31, 2017

@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 :?

[Silicon Labs] cryptographic acceleration support
Initial commit of mbed TLS hardware acceleration drivers for Silicon Labs parts

@stevew817 stevew817 force-pushed the SiliconLabs:feature/mbedtls-hw-accel branch to 1e51dfa Aug 1, 2017

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

@stevew817

This comment has been minimized.

Contributor

stevew817 commented Aug 1, 2017

@theotherjimmy Rebased and renamed.

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Aug 1, 2017

Excelent. Let's do some reviewing!

@screamerbg

This comment has been minimized.

Member

screamerbg commented Aug 2, 2017

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

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

This comment has been minimized.

@RonEld

RonEld Aug 2, 2017

Contributor

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.

This comment has been minimized.

@stevew817

stevew817 Aug 2, 2017

Contributor

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

This comment has been minimized.

@andresag01

andresag01 Sep 14, 2017

Contributor

@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...

This comment has been minimized.

@yanesca

yanesca Sep 25, 2017

Contributor

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?

This comment has been minimized.

@stevew817

stevew817 Oct 19, 2017

Contributor
  • 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.
{
uint32_t temp[4];
CRYPTO_DataRead(reg, temp);
memcpy((void*)val, temp, 16);

This comment has been minimized.

@RonEld

RonEld Aug 2, 2017

Contributor

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

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

This comment has been minimized.

@RonEld

RonEld Aug 2, 2017

Contributor

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

This comment has been minimized.

@stevew817

stevew817 Aug 2, 2017

Contributor

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.

This comment has been minimized.

@RonEld

RonEld Aug 7, 2017

Contributor

ok

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

This comment has been minimized.

@RonEld

RonEld Aug 2, 2017

Contributor

Keep in mind that once ARMmbed/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

This comment has been minimized.

@stevew817

stevew817 Aug 2, 2017

Contributor

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

This comment has been minimized.

@RonEld

RonEld Aug 7, 2017

Contributor

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

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

This comment has been minimized.

@RonEld

RonEld Aug 2, 2017

Contributor

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

This comment has been minimized.

@stevew817

stevew817 Aug 2, 2017

Contributor

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.

This comment has been minimized.

@RonEld

RonEld Aug 7, 2017

Contributor

ok , thanks

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

This comment has been minimized.

@RonEld

RonEld Aug 2, 2017

Contributor

same comment on the critical section

This comment has been minimized.

@stevew817

stevew817 Aug 2, 2017

Contributor

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

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

This comment has been minimized.

@RonEld

RonEld Aug 2, 2017

Contributor

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

This comment has been minimized.

@stevew817

stevew817 Aug 2, 2017

Contributor

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.

This comment has been minimized.

@RonEld

RonEld Aug 7, 2017

Contributor

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

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

This comment has been minimized.

@RonEld

RonEld Aug 2, 2017

Contributor

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

This comment has been minimized.

@stevew817

stevew817 Aug 2, 2017

Contributor

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.

This comment has been minimized.

@RonEld

RonEld Aug 7, 2017

Contributor

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

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

This comment has been minimized.

@RonEld

RonEld Aug 2, 2017

Contributor

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

This comment has been minimized.

@stevew817

stevew817 Aug 2, 2017

Contributor

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.

This comment has been minimized.

@RonEld

RonEld Aug 7, 2017

Contributor

ok

#define MBEDTLS_AES_ALT
#define MBEDTLS_ECP_INTERNAL_ALT
#define ECP_SHORTWEIERSTRASS

This comment has been minimized.

@RonEld

RonEld Aug 2, 2017

Contributor

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

This comment has been minimized.

@stevew817

stevew817 Aug 2, 2017

Contributor

Okay.

Apply feedback from @RonEld
* 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

This comment has been minimized.

Contributor

stevew817 commented Aug 2, 2017

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

@stevew817

This comment has been minimized.

Contributor

stevew817 commented Aug 3, 2017

@0xc0170 why did uvisor CI fail?

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Aug 3, 2017

retest uvisor

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Aug 3, 2017

@0xc0170 why did uvisor CI fail?

Jenkins error, needs restart

@stevew817

This comment has been minimized.

Contributor

stevew817 commented Aug 3, 2017

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

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Aug 3, 2017

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

@stevew817

This comment has been minimized.

Contributor

stevew817 commented Aug 7, 2017

@RonEld did I satisfy your concerns?

@RonEld

This comment has been minimized.

Contributor

RonEld commented Aug 7, 2017

@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

This comment has been minimized.

Contributor

stevew817 commented Aug 7, 2017

@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

This comment has been minimized.

Contributor

RonEld commented Aug 7, 2017

@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

This comment has been minimized.

Contributor

stevew817 commented Aug 7, 2017

@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

This comment has been minimized.

Contributor

RonEld commented Aug 7, 2017

OK, thanks

@stevew817

This comment has been minimized.

Contributor

stevew817 commented Aug 8, 2017

@RonEld Do I need a review from anyone else?

@RonEld

This comment has been minimized.

Contributor

RonEld commented Aug 8, 2017

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

@stevew817

This comment has been minimized.

Contributor

stevew817 commented Oct 31, 2017

@adbridge done.

@stevew817

This comment has been minimized.

Contributor

stevew817 commented Nov 2, 2017

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

@adbridge

This comment has been minimized.

Contributor

adbridge commented Nov 6, 2017

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

@hanno-arm

This comment has been minimized.

Contributor

hanno-arm commented Nov 6, 2017

@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-arm

This comment has been minimized.

Contributor

hanno-arm commented Nov 7, 2017

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

@adbridge

This comment has been minimized.

Contributor

adbridge commented Nov 7, 2017

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

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Nov 8, 2017

/morph build

@mbed-ci

This comment has been minimized.

mbed-ci commented Nov 8, 2017

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

This comment has been minimized.

@Patater

Patater suggested changes Nov 10, 2017 edited

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).

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

This comment has been minimized.

@Patater

Patater Nov 10, 2017

Contributor

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)

This comment has been minimized.

@stevew817

stevew817 Nov 11, 2017

Contributor

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.

This comment has been minimized.

@Patater

Patater Nov 13, 2017

Contributor

OK.

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

processed++;
}
crypto_management_release(device);

This comment has been minimized.

@Patater

Patater Nov 10, 2017

Contributor

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.

This comment has been minimized.

@stevew817

stevew817 Nov 11, 2017

Contributor

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

This comment has been minimized.

@Patater

Patater Nov 13, 2017

Contributor

OK.

I now see crypto_management_release is inside the else body.

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

This comment has been minimized.

@Patater

Patater Nov 10, 2017

Contributor

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.

This comment has been minimized.

@stevew817

stevew817 Nov 11, 2017

Contributor

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.

This comment has been minimized.

@Patater

Patater Nov 13, 2017

Contributor

OK.

I now see crypto_management_release is inside the else body.

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);

This comment has been minimized.

@Patater

Patater Nov 10, 2017

Contributor

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 comment has been minimized.

@stevew817

stevew817 Nov 11, 2017

Contributor

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.

#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));

This comment has been minimized.

@Patater

Patater Nov 10, 2017

Contributor

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));

This comment has been minimized.

@stevew817

stevew817 Nov 11, 2017

Contributor

okay

* limitations under the License.
*/
#ifndef MBEDTLS_CRYPTO_MANAGEMENT_H

This comment has been minimized.

@Patater

Patater Nov 10, 2017

Contributor

Don't use MBEDTLS prefix here, please.

This comment has been minimized.

@stevew817

stevew817 Nov 11, 2017

Contributor

okay

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

This comment has been minimized.

@Patater

Patater Nov 10, 2017

Contributor

Consider making a #define for 64.

This comment has been minimized.

@stevew817

stevew817 Nov 11, 2017

Contributor

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?

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

This comment has been minimized.

@Patater

Patater Nov 10, 2017

Contributor

Consider making a #define for 32.

This comment has been minimized.

@stevew817

stevew817 Nov 11, 2017

Contributor

Sure.

@@ -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"],

This comment has been minimized.

@Patater

Patater Nov 10, 2017

Contributor

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

This comment has been minimized.

@stevew817

stevew817 Nov 11, 2017

Contributor

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

@@ -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"],

This comment has been minimized.

@Patater

Patater Nov 10, 2017

Contributor

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

This comment has been minimized.

@stevew817

stevew817 Nov 11, 2017

Contributor

Oops. Fixed.

@ashok-rao

This comment has been minimized.

Contributor

ashok-rao commented Nov 10, 2017

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

@stevew817

This comment has been minimized.

Contributor

stevew817 commented Nov 10, 2017

@ashok-rao @Patater Will do.

@Patater

LGTM

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

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Nov 13, 2017

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

This comment has been minimized.

mbed-ci commented Nov 13, 2017

@mbed-ci

This comment has been minimized.

mbed-ci commented Nov 13, 2017

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

This comment has been minimized.

Contributor

theotherjimmy commented Nov 13, 2017

/morph test
/morph uvisor-test

@mbed-ci

This comment has been minimized.

@mbed-ci

This comment has been minimized.

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

6 checks passed

AWS-CI uVisor Build & Test Success
Details
ci-morph-build build completed
Details
ci-morph-exporter build completed
Details
ci-morph-test test completed
Details
continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment