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

[TLS / hw acceleration] AES ECB for NUCLEO_F439ZI #3691

Merged
merged 6 commits into from Mar 14, 2017

Conversation

Projects
None yet
10 participants
@adustm
Member

adustm commented Feb 3, 2017

Description

This pull request contains the very first HW acceleration for STM devices
Could you review it and let us know if it fits the requested process for HW acceleration in mbedtls feature ?
I've also added aes in TESTS/mbedtls/selftest/main.cpp
+---------------------------+--------+--------+--------+
| test case | passed | failed | result |
+---------------------------+--------+--------+--------+
| mbedtls_aes_self_test | 1 | 0 | OK |
| mbedtls_entropy_self_test | 1 | 0 | OK |
| mbedtls_sha256_self_test | 1 | 0 | OK |
| mbedtls_sha512_self_test | 1 | 0 | OK |
+---------------------------+--------+--------+--------+

Once we agree on this files format and structure, we will be able to add soon AES-CBC mode, SHA1 etc...

Status

READY

Steps to test or reproduce

mbed test -m NUCLEO_F439ZI -t IAR -n tests-mbedtls-selftest

cc @bcostm @screamerbg @sbutcher-arm @0xc0170

@jeromecoutant

This comment has been minimized.

Contributor

jeromecoutant commented Feb 3, 2017

Hi
Is it OK to add some TARGET_xxx files in the features directory ?
Could we move these files into targets directory ?

@adustm

This comment has been minimized.

Member

adustm commented Feb 6, 2017

Hi @jeromecoutant
It would be nice but I don't know the impact on code size etc...

@0xc0170 ?
Jerome and I would like to move mbedtls/target_STM code to the usual mbed-os/targets/... TARGET_STM directory.
Do you know if we can do that or not ? What is the impact of doing this ?

Kind regards
Armelle

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Feb 6, 2017

Jerome and I would like to move mbedtls/target_STM code to the usual mbed-os/targets/... TARGET_STM directory.
Do you know if we can do that or not ? What is the impact of doing this ?

@sbutcher-arm Please review this PR.

@0xc0170 0xc0170 requested a review from sbutcher-arm Feb 6, 2017

@screamerbg

This comment has been minimized.

Member

screamerbg commented Feb 9, 2017

CC @RonEld

@adustm

This comment has been minimized.

Member

adustm commented Feb 14, 2017

Hello @RonEld @sbutcher-arm
Could one of you review my PR please?
Could you also let me know if we must keep STM's files in the feature directory or if we can move them to the targets usual STM directory ?

Cheers
Armelle

@sbutcher-arm

This comment has been minimized.

Contributor

sbutcher-arm commented Feb 14, 2017

Hi @adustm.

The idea of keeping the mbed TLS acceleration driver code in the features/mbedtls/targets directory is to separate out the code that uses the mbed HAL from the code that uses the mbed TLS interfaces, as well as making it clearer that code that is pushed to the HAL targets directory has a different approvals process from that pushed to the mbed TLS targets directory, as the cryptographic code needs an additional security review.

Does this present any issues for you?

We're working on reviewing this code, and we need feedback and sign-off from myself, @yanesca and @andresag01 before we can approve this PR.

@adustm

This comment has been minimized.

Member

adustm commented Feb 14, 2017

Hi @sbutcher-arm
Thank you for your comment, I'll wait for the review results.

to separate out the code that uses the mbed HAL from the code that uses the mbed TLS interfaces

features/mbedtls/targets/TARGET_STM/aes_alt.c is calling functions from targets/.../TARGET_STM32F4/device/stm32f4_hal_cryp.c

so from ST's point of view, ST code is separated out

Does this present any issues for you?

Let me try to explain the reason for this request from my colleagues and I. If we can do it, let's go, if we can't, let it go. It is ARM to decide at the end :-)

ST code is spread out in several features (mbedTLS / usb / lwip... ).
As you may know we are providing support for more than 35 platforms.
There are people working in parallel (from ST or not), not knowing into deep details the work of others.

ST code is specific for our targets:

  • we are handling the pins and call to hw functionalities for I2C / SPI / UART / etc... in targets directory
  • We are handling the pins and ST HW for the Ethernet phy in lwip feature directory + it calls ST HAL functions from targets directory
  • We are handling the call to hw acceleration in mbedtls feature directory + it calls ST HAL functions from targets directory
  • we are handling USB call in unsupported/USB directories
  • And eventually we are handling the call to hw entropy in targets directory

When every code is located in a single directory tree we maximize the chance that every ST contributor is aware of the changes coming from others, and is better aware of the impact of his/her changes.

mbed compilation and link mechanism is creating a long list of include directories, so the code could be located here or there, I think it has no impact, has it ?

Anyway I have written this pull request following the specification (ST code in features/mbedtls).
The whole discussion is coming from an internal remark we had between ST people. We can now decide to take it into account or classify the discussion.

Kind regards
Armelle
cc @jeromecoutant @LMESTM @bcostm @jamike

@sbutcher-arm

This comment has been minimized.

Contributor

sbutcher-arm commented Feb 14, 2017

Hi @adustm,

I think this is a useful discussion, and we have been seeking feedback from partners on the hardware acceleration interfaces. However, this is going outside the scope of this PR, and it may be more useful to discuss this directly.

To clarify - the targets directory is concerned with the mbed HAL and the interfaces mbed OS presents. mbed TLS has a life outside of mbed OS and is used on other platforms, and has separate and distinct interfaces itself. For instance, note mbed OS has a TRNG HAL API, whereas mbed TLS has it's own entropy interface, a mbed OS platform code brings the two interfaces together.

I think it's understandable that platform/SoC/driver code that might reside in the TARGETS directory may be called by driver code in the mbed TLS code driving the hardware acceleration code. I don't think that is an issue, and you are correct to say we could place the sources in other places (and indeed could move them later). This is really about logical organisation and management.

@andresag01

I have done an initial review and found the following:

  • There are some issues with the use of the _ALT macros.
  • I do not think this code is thread safe.
  • I think there is an opportunity to reconcile the mbedtls_aes_context structure with CRYP_HandleTypeDef as some of the data is duplicated, unused or redundant.
  • Pointed out places where the function return codes are not checked for errors.
features/mbedtls/targets/TARGET_STM/TARGET_STM32F4/TARGET_NUCLEO_F439ZI/mbedtls_device.h Outdated
#define MBEDTLS_AES_SETKEY_ENC_ALT
#define MBEDTLS_AES_SETKEY_DEC_ALT
#define MBEDTLS_AES_ENCRYPT_ALT
#define MBEDTLS_AES_DECRYPT_ALT

This comment has been minimized.

@andresag01

andresag01 Feb 15, 2017

Contributor

The AES module supports replacing the full module by defining the macro MBEDTLS_AES_ALT or replacing functions by defining the macros MBEDTLS_AES_SETKEY_ENC_ALT, MBEDTLS_AES_ENCRYPT_ALT, etc... However, it is my understanding that when MBEDTLS_AES_ALT is defined, the function specific replacement macros become irrelevant, so I do not think it makes sense to define these here.

This comment has been minimized.

@andresag01

andresag01 Feb 15, 2017

Contributor

I think that this file should contain the macro definition for MBEDTLS_AES_ALT instead of the targets.json file.

This comment has been minimized.

@adustm

adustm Feb 17, 2017

Member

Ok I will try that

features/mbedtls/targets/TARGET_STM/aes_alt.c Outdated
*/
#if defined(MBEDTLS_AES_ALT)
#include <stdio.h>

This comment has been minimized.

@andresag01

andresag01 Feb 15, 2017

Contributor

Because this is mbed TLS related code, I would advise to include the mbed TLS platform abstraction header (i.e. mbedtls/platform.h) instead of stdio.h, unless there is good reason to do this.

This comment has been minimized.

@andresag01

andresag01 Feb 15, 2017

Contributor

I had a look at all the code in this file and it does not look like there are references to any symbols from stdio.h. Could you please remove this include, or explain why it is required?

This comment has been minimized.

@andresag01

andresag01 Feb 15, 2017

Contributor

The code in this file uses a few macros such as MBEDTLS_CIPHER_MODE_CTR which are defined in mbedtls/config.h, but the file is not included here.

This comment has been minimized.

@adustm

adustm Feb 17, 2017

Member

thanks I will check these

features/mbedtls/targets/TARGET_STM/aes_alt.c Outdated
#include <stdio.h>
#include "cmsis.h"
#include "string.h"
#include "aes.h"

This comment has been minimized.

@andresag01

andresag01 Feb 15, 2017

Contributor

I think this is including the mbed TLS header file for the AES module. If this is the case, I would encourage to modify the include to #include "mbedtls/aes.h" to avoid any aliasing problems.

This comment has been minimized.

@adustm
features/mbedtls/targets/TARGET_STM/aes_alt.c Outdated
* \brief Initialize AES context
*
* \param ctx AES context to be initialized
*/

This comment has been minimized.

@andresag01

andresag01 Feb 15, 2017

Contributor

Style: Normally, the doxygen-style documentation for each module should be written in the header file instead of the .c file. So, I would advise to remove these doxygen comment blocks. Furthermore, the aes_alt.h file already contains the same comment blocks.

This comment has been minimized.

@adustm
targets/targets.json Outdated
@@ -899,7 +899,7 @@
"extra_labels": ["STM", "STM32F4", "STM32F439", "STM32F439ZI", "STM32F439xx", "F429_F439"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
"progen": {"target": "nucleo-f439zi"},
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2"],
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2", "MBEDTLS_CONFIG_HW_SUPPORT", "MBEDTLS_AES_ALT"],

This comment has been minimized.

@andresag01

andresag01 Feb 15, 2017

Contributor

I think the targets.json should not contain defines such as MBEDTLS_AES_ALT. Instead, these defines are expected to be in the mbedtls_device.h file.

This comment has been minimized.

@adustm

adustm Feb 17, 2017

Member

I will try that

This comment has been minimized.

@adustm

adustm Feb 17, 2017

Member

Thank you very much @andresag01 for this detailled and interesting review :+1
I will rework that and send updates

features/mbedtls/targets/TARGET_STM/aes_alt.c Outdated
return(MBEDTLS_ERR_AES_INVALID_KEY_LENGTH);
/*------------------ AES Decryption ------------------*/
if(mode == MBEDTLS_AES_DECRYPT) /* AES decryption */

This comment has been minimized.

@andresag01

andresag01 Feb 15, 2017

Contributor

This comment is a little redundant...

This comment has been minimized.

@adustm
features/mbedtls/targets/TARGET_STM/aes_alt.c Outdated
mbedtls_aes_decrypt( ctx, input, output );
}
/*------------------ AES Encryption ------------------*/
else /* AES encryption */

This comment has been minimized.

@andresag01

andresag01 Feb 15, 2017

Contributor

This comment is a little redundant

features/mbedtls/targets/TARGET_STM/aes_alt.c Outdated
// unaccelerated mode
//
}
#endif

This comment has been minimized.

@andresag01

andresag01 Feb 15, 2017

Contributor

I think this block of code is only for x86 machines. Please consider removing it...

This comment has been minimized.

@adustm
features/mbedtls/targets/TARGET_STM/aes_alt.c Outdated
unsigned char output[16] )
{
HAL_CRYP_AESECB_Encrypt(&hcryp_aes, (uint8_t *)input, 16, (uint8_t *)output, 10);

This comment has been minimized.

@andresag01

andresag01 Feb 15, 2017

Contributor

I think it would be good to check this function's return code for errors.

This comment has been minimized.

@adustm

adustm Feb 17, 2017

Member

it does return timeout for instance. but mbedtls_aes_encrypt returns void. How do you usually handle it ?

This comment has been minimized.

@sbutcher-arm

sbutcher-arm Feb 23, 2017

Contributor

I think we have an issue here. The interface was originally designed for a software implementation of AES and was later re-purposed for other implementations.

Here, I don't think the interface suits what we're trying to achieve in hardware, therefore I think we should deprecate this interface, and implement a new interface which enables a error return code.

@andresag01 - Can you raise an issue/enhancement on the mbed TLS github repo?

@adustm - I think we can accept this code as it is at the moment, but we'll probably want to refine this code to work with a new interface later. In the meantime, can we remove the mbedtls_printf() and replace it with a comment?

This comment has been minimized.

@andresag01

andresag01 Feb 23, 2017

Contributor

@sbutcher-arm: I have raised the new issue in the mbed TLS repository at ARMmbed/mbedtls#817

features/mbedtls/targets/TARGET_STM/aes_alt.c Outdated
unsigned char output[16] )
{
HAL_CRYP_AESECB_Decrypt(&hcryp_aes, (uint8_t *)input, 16, (uint8_t *)output, 10);

This comment has been minimized.

@andresag01

andresag01 Feb 15, 2017

Contributor

I think it would be good to check this function's return code for errors.

This comment has been minimized.

@adustm

adustm Feb 17, 2017

Member

same comment

@screamerbg

This comment has been minimized.

Member

screamerbg commented Feb 16, 2017

@adustm @sbutcher-arm I think there are 2 points of views:

  • how features in mbed OS are organized
  • how partner ports for targets in mbed OS are organized

I agree with @adustm about having all target support code in one place under targets. The ST team is supporting significant amount of targets and having this separation is inconvenient, makes it harder for the mbed Partner teams to maintain (it's all over the place already) and reduces the chance for community contributions.

@sbutcher-arm wrote:
mbed TLS has a life outside of mbed OS and is used on other platforms, and has separate and distinct interfaces itself.

This PR is not to the mbed TLS specifically (e.g. this is not http://github.com/ARMmbed/mbedtls), but to extend an existing target support in mbed OS for TLS features. If the TLS team would like to request from ST to contribute this HW crypto support to http://github.com/ARMmbed/mbedtls then please follow the formal process via email.

Also if there is visibility issue, then this could be addressed by adding a label for the ARM mbed TLS team to review.

Perhaps this is a wider question (hence cc @sg-):

  • where do features live - currently in /features
  • where do drivers code live - currently in /targets for some, but /features for other
  • where do glue layers live - currently /targets for HAL, LWIP /features/FEATURE_LWIP

Also it's important to understand the maintainability point of view, e.g. how much code mbed Partner teams are managing.

For example, the following structure may satisfy both ST team code maintenance and glue layers for features support

/targets
 -> TARGET_<vendor>
 ---> TARGET_<mcu_family>
-------> FEATURE_LWIP
-----------> all LWIP driver code and glue layer for that MCU family

With this structure the feature driver code and the feature glue layer for would be gated by the presence of the feature (meaning that it won't be compiled if the feature is not enabled). Also it would be in one place from mbed Partner maintenance point of view.

@sg-

This comment has been minimized.

Member

sg- commented Feb 16, 2017

Top level target code is organized to contain MCU SDKs and a binding to the mbed HAL. Any feature integrated as a mbed HAL interface and enabled by device_has should remain in feature/xxx/TARGET_xxx At the point a mbed HAL interface and tests come available for a features integration the implementation should move into the top level targets directory.

In this case, I agree with @sbutcher-arm

The idea of keeping the mbed TLS acceleration driver code in the features/mbedtls/targets directory is to separate out the code that uses the mbed HAL from the code that uses the mbed TLS interfaces, as well as making it clearer that code that is pushed to the HAL targets directory has a different approvals process from that pushed to the mbed TLS targets directory, as the cryptographic code needs an additional security review.

From the developer guide for hardware acceleration: https://docs.mbed.com/docs/mbed-os-handbook/en/latest/advanced/tls_hardware_acceleration/#how-to-implement-the-functions

Clone the mbed OS repository and copy the source code of your function definitions to the features/mbedtls/targets/TARGET_XXXX directory specific to your target. Create a pull request when your code is finished and production ready. You may create a directory structure similar to the one you have for the HAL if you feel it appropriate.

@adustm

This comment has been minimized.

Member

adustm commented Feb 16, 2017

Hello,
Thank you @screamerbg and @sg- for your answers and comments.
I think the discussion can be closed.

I'll start working on the PR review comments.
Kind regards

@adustm

This comment has been minimized.

Member

adustm commented Feb 17, 2017

Hi @andresag01
I've reworked the code following your recommendations.
MBEDTLSxxx_ALT tags should be well handled
I've added AES_CBC hw acceleration
AND : I've fixed the 'not thread safe' issue you pointed out (and now I have CTR-DRBG ok)

image

I hope everything will be fine now.
Kind regards
Armelle

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Feb 21, 2017

Another round of review please?

retest uvisor

@adustm

This comment has been minimized.

Member

adustm commented Feb 23, 2017

Hello, is there anything blocking ?

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Feb 23, 2017

There's a conflict to be resolved

@andresag01 @sbutcher-arm please review

@andresag01

@adustm: Thanks for taking into account the previous review comments. I have reviewed the code once more and most of the issues I pointed out seem to have been resolved.

From my point of view, there are still a couple of issues left:

  • The functions mbedtls_aes_encrypt() and mbedtls_aes_decrypt() do nor have return values, making difficult to check whether the crypto accelerator succeeded. This touches on the API design, so I have raised the issue ARMmbed/mbedtls#817.
  • There have been some improvements, but I do not think that this code is thread-safe. Normally, we achieve this in mbed TLS by using the threading API (threading.h). Please note that there is a PR to add support for this: #3150
@RonEld

This comment has been minimized.

Contributor

RonEld commented Feb 23, 2017

I have looked in the changes, and I saw that there is many code duplicity, and copy\paste from the sw implementation. I beleive this is due to the current implementation of the HW configuration. This code duplication could have been resolved by MBEDTLS_AES_SETKEY_ENC_ALT , MBEDTLS_AES_SETKEY_DEC_ALT , MBEDTLS_AES_ENCRYPT_ALT , MBEDTLS_AES_DECRYPT_ALT , but the mbedtls_aes_context needs to be modified to support the HW AES, and this is currently not possible without MBEDTLS_AES_ALT.
According to that, I opened a github enhancement request , that I believe could remove this duplicity.
Other than that, the changes look good to me

@sbutcher-arm

Requires minor changes, but otherwise approved by me.

features/mbedtls/targets/TARGET_STM/aes_alt.c Outdated
unsigned char output[16] )
{
if (HAL_CRYP_AESECB_Encrypt(&ctx->hcryp_aes, (uint8_t *)input, 16, (uint8_t *)output, 10) !=0)

This comment has been minimized.

@sbutcher-arm

sbutcher-arm Feb 28, 2017

Contributor

We've identified that we need to change this function so it can return an error code, but until we do, I don't think we should be calling mbedtls_printf() here, unless it's restricted to be in just debug builds or similar.

This comment has been minimized.

@adustm

adustm Feb 28, 2017

Member

hello @sbutcher-arm
Do you suggest that I remove the mbedtls_printf and replace it by a comment line
/* return error code once mbedtls_aes_encrypt and mbedtls_aes_decrypt functions will return one */
?

features/mbedtls/targets/TARGET_STM/aes_alt.c Outdated
{
if(HAL_CRYP_AESECB_Decrypt(&ctx->hcryp_aes, (uint8_t *)input, 16, (uint8_t *)output, 10))
mbedtls_printf( "HAL_CRYP_AESECB_Decrypt timeout\n" );

This comment has been minimized.

@sbutcher-arm

sbutcher-arm Feb 28, 2017

Contributor

Same point as above on mbedtls_printf().

This comment has been minimized.

@adustm

adustm Feb 28, 2017

Member

same question as above

@sbutcher-arm

This comment has been minimized.

Contributor

sbutcher-arm commented Feb 28, 2017

Hi @adustm,

Looking over the code, and based on the feedback from @andresag01 and @RonEld, I can see we need to refine the hardware acceleration interface that mbed TLS presents. I don't want those changes to hold up this work, so we'll do that independently and then later can revise this code to take advantage of those changes. Please feel free to provide more feedback on those changes.

Thanks for your patience as we've worked through this pull request.

My only concern is the calls to mbedtls_printf() in case of an error, but that more shows a problem in our interfaces than your code.

@adustm

This comment has been minimized.

Member

adustm commented Feb 28, 2017

Hello @RonEld
Your comment about thread safety is not clear to me and the PR you're pointing at is not merged.
Do you have a document, or a code example that I could read to understand better ?

Thank you to the 3 reviewers
Kind regards

adustm added some commits Feb 28, 2017

AES ECB for NUCLEO_F439ZI
+---------------------------+--------+--------+--------+
| test case                 | passed | failed | result |
+---------------------------+--------+--------+--------+
| mbedtls_aes_self_test     | 1      | 0      | OK     |
| mbedtls_entropy_self_test | 1      | 0      | OK     |
| mbedtls_sha256_self_test  | 1      | 0      | OK     |
| mbedtls_sha512_self_test  | 1      | 0      | OK     |
+---------------------------+--------+--------+--------+
Better use of MBEDTLS_AES_ALT
  removed from targets.json, added in mbedtls_device.h
  remove function alternate defines (not used as we replace the full
  module)
Big commit after code review from andesag01
cleanup in include files (unrequired removed + other moved to aes_alt.h)
hcryp_aes moved to mbedtls_aes_context to allow multi instances
remove ctx->nr, ctx->buf
doxygen comments are removed (kept in .h file)
function _ALT are removed (full module _ALT)
handle error returned by HAL_CRYPxx functions
aes is symetric, remove the dupplicated set_key_enc and set_key_dec
buffer, and factorize the call to set_key function

@adustm adustm force-pushed the adustm:STM_aes_f439zi branch Feb 28, 2017

@adustm adustm force-pushed the adustm:STM_aes_f439zi branch to 5c858a4 Feb 28, 2017

@adustm

This comment has been minimized.

Member

adustm commented Feb 28, 2017

Hello, I've removed the mbedtls_printf error notifications
I did not change the thread safety nor the code dupplicity as they will be treated separately.
Kind regards

@sbutcher-arm

This comment has been minimized.

Contributor

sbutcher-arm commented Feb 28, 2017

@adustm - Thanks. The PR is fine by me now. There are outstanding changes but we should revisit these when we've done the necessary changes to mbed TLS.

@adustm

This comment has been minimized.

Member

adustm commented Mar 3, 2017

Hello @0xc0170 I think the 'need review' can be transformed into 'ready to merge'... :)

@RonEld

This comment has been minimized.

Contributor

RonEld commented Mar 6, 2017

Hi @adustm
I believe your question on the thread safety should be referred to @andresag01

@adustm

This comment has been minimized.

Member

adustm commented Mar 7, 2017

Hello @andresag01, @sbutcher-arm @RonEld
About the comment from Andres

There have been some improvements, but I do not think that this code is thread-safe. Normally, we achieve this in mbed TLS by using the threading API (threading.h). Please note that there is a PR to add support for this: #3150

I have read PR#3150 but it is not clear to me what you are waiting for: shall I wait until this thread PR is integrated in mbed-tls then in mbed-os ? What would be the impact to my code ?

Or can it be treated separately in another PR later on ? I have work about AES for 2 other platforms + SHA1 and SHA256 that are pending the integration of the current PR. I would like to be able to progress on the subject.
I think 0xc0170 is waiting for your green light.
Kind regards

@sbutcher-arm

This comment has been minimized.

Contributor

sbutcher-arm commented Mar 7, 2017

As I said above, @andresag01's points are valid, but I don't think we should hold up this PR for the work on thread safety it depends on.

@0xc0170 - this PR is ready to merge. We know it has issues, but they're dependent on changes in mbed TLS and can be fixed later.

@0xc0170 0xc0170 added needs: CI and removed needs: review labels Mar 7, 2017

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Mar 7, 2017

/morph test-nightly

@mbed-bot

This comment has been minimized.

mbed-bot commented Mar 7, 2017

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1648

Build failed!

@screamerbg

This comment has been minimized.

Member

screamerbg commented Mar 9, 2017

/morph test

@mbed-bot

This comment has been minimized.

mbed-bot commented Mar 9, 2017

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1660

Build failed!

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Mar 9, 2017

@bridadan Need you eye. The failures are about sections overflow.

@adustm The selftest change should not affect other targets or? You can view the failures : http://mbedosci.cloudapp.net/results/pr/3691/1660

From the failures, looks like the test does not fit to many devices that are tested.

@adustm

This comment has been minimized.

Member

adustm commented Mar 9, 2017

Hello,
I can see that some failure are due to code size. I've added AES test in the self test to show how I have validated the modification, but I can remove this file from the PR.

@adustm

This comment has been minimized.

Member

adustm commented Mar 9, 2017

Thanks @0xc0170 for sharing the build output failure.
I have fixed it. It should be ok now.
Cheers

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Mar 9, 2017

/morph test-nightly

@mbed-bot

This comment has been minimized.

mbed-bot commented Mar 9, 2017

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1665

All builds and test passed!

@0xc0170 0xc0170 added ready for merge and removed needs: CI labels Mar 14, 2017

@adbridge adbridge merged commit e743a26 into ARMmbed:master Mar 14, 2017

4 checks passed

Cam-CI uvisor Build & Test Success
Details
ci/morph-test-nightly Job has started
Details
continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@adustm adustm deleted the adustm:STM_aes_f439zi branch May 29, 2017

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