Skip to content
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

Port mbed TLS self test to greentea #2603

Merged
merged 1 commit into from
Sep 30, 2016
Merged

Conversation

andresag01
Copy link

@andresag01 andresag01 commented Sep 1, 2016

This set of tests is a port of the mbed TLS test program at mbedtls/programs/test/selftest.c. The test executes the mbedtls_*_self_test() functions in the library modules and checks the output (PASS, FAIL). This patch ports the self test program to use mbedgt instead but maintains the same functionality.

@andresag01
Copy link
Author

@sbutcher-arm @yanesca @pjbakker: This patch addresses IOTSSL-941.

@andresag01 andresag01 changed the title Port mbed TLS self test to greentea DRAFT: Port mbed TLS self test to greentea Sep 2, 2016
@andresag01 andresag01 changed the title DRAFT: Port mbed TLS self test to greentea Port mbed TLS self test to greentea Sep 2, 2016
@bridadan
Copy link
Contributor

bridadan commented Sep 7, 2016

@andresag01 Sorry for not looking at this sooner! It looks good, but the entropy test fails for targets that don't have the MBEDTLS_ENTROPY_HARDWARE_ALT macro set. Is this expected behavior? If so, could you add one more check for this macro before enabling the entropy test?

@andresag01
Copy link
Author

@bridadan thanks for having a look at this pull request. Could you please let us know what are the targets that fail? I presume that the reason for the failure is because they do not have entropy source enabled, which part of what we wanted to test. I am not sure what is the intended behaviour in this case, what do @yanesca, @sbutcher-arm and @pjbakker think?

@screamerbg
Copy link
Contributor

@adustm Please let me know if you're able to run the tests in this PR against the HW entropy for STM32 that you recently implemented.

@bridadan
Copy link
Contributor

bridadan commented Sep 8, 2016

@andresag01 I think that's probably the case, though I admit I'm not all that familiar with mbedTLS and the entropy sources.

If that test cannot pass on targets that don't support the entropy source yet, then I would think it doesn't make sense to run the test since there's no way it will pass. Instead it should be ran only when the feature is enabled.

@sg-
Copy link
Contributor

sg- commented Sep 9, 2016

The test could be gated by the macro as others are

#if !MBEDTLS_ENTROPY_HARDWARE_ALT
    #error [NOT_SUPPORTED] IPV4 not supported for this target
#endif

@sg- sg- added the needs: work label Sep 9, 2016
@adustm
Copy link
Member

adustm commented Sep 12, 2016

Hello,
I agree with @-sg, you should add the error reporting if the target does not support the mbedTLS entropy.
However I have tested it with one of ST boards that has the HW_entropy enabled. It works fine.
Here is the outcome for NUCLEO_F746ZG :

mbed test -m NUCLEO_F746ZG -t GCC_ARM -n tests-mbedtls-selftest
Build successes:
  * NUCLEO_F746ZG::GCC_ARM::MBED-BUILD
  * NUCLEO_F746ZG::GCC_ARM::TESTS-MBEDTLS-SELFTEST
mbedgt: greentea test automation tool ver. 1.2.0
mbedgt: test specification file 'C:\MCDGitW601\mbed\.build/tests\NUCLEO_F746ZG\GCC_ARM\test_spec.json' (specified with --test-spec option)
mbedgt: using 'C:\MCDGitW601\mbed\.build/tests\NUCLEO_F746ZG\GCC_ARM\test_spec.json' from current directory!
mbedgt: detecting connected mbed-enabled devices...
mbedgt: detected 1 device
mbedgt: processing target 'NUCLEO_F746ZG' toolchain 'GCC_ARM' compatible platforms... (note: switch set to --parallel 1)
mbedgt: test case filter (specified with -n option)
        test filtered in 'tests-mbedtls-selftest'
mbedgt: running 1 test for platform 'NUCLEO_F746ZG' and toolchain 'GCC_ARM'
mbedgt: mbed-host-test-runner: started
mbedgt: checking for GCOV data...
mbedgt: test on hardware with target id: 08160221054560033A01F928
mbedgt: test suite 'tests-mbedtls-selftest' .......................................................... OK in 17.30 sec
        test case: 'mbedtls_aes_self_test' ........................................................... OK in 0.49 sec
        test case: 'mbedtls_base64_self_test' ........................................................ OK in 0.05 sec
        test case: 'mbedtls_ccm_self_test' ........................................................... OK in 0.05 sec
        test case: 'mbedtls_ctr_drbg_self_test' ...................................................... OK in 0.05 sec
        test case: 'mbedtls_ecp_self_test' ........................................................... OK in 1.88 sec
        test case: 'mbedtls_entropy_self_test' ....................................................... OK in 0.06 sec
        test case: 'mbedtls_gcm_self_test' ........................................................... OK in 0.05 sec
        test case: 'mbedtls_hmac_drbg_self_test' ..................................................... OK in 0.05 sec
        test case: 'mbedtls_mpi_self_test' ........................................................... OK in 0.07 sec
        test case: 'mbedtls_rsa_self_test' ........................................................... OK in 0.14 sec
        test case: 'mbedtls_sha256_self_test' ........................................................ OK in 0.30 sec
        test case: 'mbedtls_sha512_self_test' ........................................................ OK in 0.93 sec
        test case: 'mbedtls_x509_self_test' .......................................................... OK in 0.05 sec
mbedgt: test case summary: 13 passes, 0 failures
mbedgt: all tests finished!
mbedgt: shuffle seed: 0.5399348762
mbedgt: test suite report:
+-----------------------+---------------+------------------------+--------+--------------------+-------------+
| target                | platform_name | test suite             | result | elapsed_time (sec) | copy_method |
+-----------------------+---------------+------------------------+--------+--------------------+-------------+
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | OK     | 17.3               | shell       |
+-----------------------+---------------+------------------------+--------+--------------------+-------------+
mbedgt: test suite results: 1 OK
mbedgt: test case report:
+-----------------------+---------------+------------------------+-----------------------------+--------+--------+--------+--------------------+
| target                | platform_name | test suite             | test case                   | passed | failed | result | elapsed_time (sec) |
+-----------------------+---------------+------------------------+-----------------------------+--------+--------+--------+--------------------+
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | mbedtls_aes_self_test       | 1      | 0      | OK     | 0.49               |
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | mbedtls_base64_self_test    | 1      | 0      | OK     | 0.05               |
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | mbedtls_ccm_self_test       | 1      | 0      | OK     | 0.05               |
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | mbedtls_ctr_drbg_self_test  | 1      | 0      | OK     | 0.05               |
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | mbedtls_ecp_self_test       | 1      | 0      | OK     | 1.88               |
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | mbedtls_entropy_self_test   | 1      | 0      | OK     | 0.06               |
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | mbedtls_gcm_self_test       | 1      | 0      | OK     | 0.05               |
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | mbedtls_hmac_drbg_self_test | 1      | 0      | OK     | 0.05               |
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | mbedtls_mpi_self_test       | 1      | 0      | OK     | 0.07               |
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | mbedtls_rsa_self_test       | 1      | 0      | OK     | 0.14               |
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | mbedtls_sha256_self_test    | 1      | 0      | OK     | 0.3                |
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | mbedtls_sha512_self_test    | 1      | 0      | OK     | 0.93               |
| NUCLEO_F746ZG-GCC_ARM | NUCLEO_F746ZG | tests-mbedtls-selftest | mbedtls_x509_self_test      | 1      | 0      | OK     | 0.05               |
+-----------------------+---------------+------------------------+-----------------------------+--------+--------+--------+--------------------+
mbedgt: test case results: 13 OK
mbedgt: completed in 17.45 sec

LGTM

Cheers
Armelle

@bridadan
Copy link
Contributor

@sg- It should be noted that the the NOT_SUPPORTED functionality only works at compile time. So if you want the other tests to be built/ran even if the the hardware entropy source is not present, these tests will need to be moved into a different test file.

For example, TESTS/mbedtls/selftest/selftest.cpp for all tests that don't have a dependency on the hardware entropy source, and TESTS/mbedtls/hardware_entropy/hardware_entropy.cpp for tests that DO have a dependency on the hardware entropy source. The latter file would have the following check at the top of the code:

#if !MBEDTLS_ENTROPY_HARDWARE_ALT
    #error [NOT_SUPPORTED] Hardware entropy not supported for this target
#endif

@bridadan
Copy link
Contributor

@andresag01 Probably should have tagged you in the above message too 😄

@adustm
Copy link
Member

adustm commented Sep 16, 2016

Hello, is there any news on the topic ?

@andresag01
Copy link
Author

andresag01 commented Sep 16, 2016

We are implementing @sbutcher-arm proposal i.e. have an additional configuration file in mbed TLS that gets included when DEVICE_ENTROPY_SOURCE is not defined in targets.json. We have prepared two PRs for this:

Mbed-TLS/mbedtls#615 (mbed TLS)
#2716 (mbed OS)

They are still marked as DRAFT because this is still work in progress.

@yanesca
Copy link
Contributor

yanesca commented Sep 27, 2016

+1

@simonbutcher
Copy link
Contributor

The pull request looks good to me.

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 28, 2016

/morph test

Copy link
Contributor

@0xc0170 0xc0170 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@mbed-bot
Copy link

Result: FAILURE

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

/morph test

Output

mbed Build Number: 980

Build failed!

@bridadan
Copy link
Contributor

@0xc0170 Looks like a few targets can't fit this test in memory. Perhaps we need to break this up into a few binaries?

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 28, 2016

@0xc0170 Looks like a few targets can't fit this test in memory. Perhaps we need to break this up into a few binaries?

@andresag01 Can you please have a look at failures, and how we can fix those?

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 29, 2016

We had a quick look, the small platforms are having problems. RAM overflows, by >1k and similar sizes, therefore might be considered if those targets are either supported or should be (memory size restrictions).

@simonbutcher
Copy link
Contributor

Because mbed TLS is a static link library you only need to build in the functions that you need, and you can leave out everything else. If you only want AES - you can link in only AES and exclude all hashing functions, X.509 support and everything else. Also, despite the fact asymmetric crypto may take a very long time on the smaller devices there may be some use cases that still want to do it if they don't care about the time taken to execute.

That means that's it's not obvious whether mbed TLS is appropriate or not for some of these tiny devices.

Therefore it still makes sense to run all tests on all devices for the moment as we can't second guess all use cases, even if some don't seem to make immediate sense.

Therefore, we'll break up the tests into smaller functional entities as @bridadan suggests to allow all tests to run. In this process we might find some of the bigger features still don't fit on the tiniest devices (such as X.509). If this is true we may look again at the feature set and see what makes sense and how to exclude such features.

@bridadan
Copy link
Contributor

@sbutcher-arm I think that's probably the simplest approach for now. The one thing I would recommend is to try pairing some of the lightweight and related functions in the same test binary instead of creating one binary for each function. The reason being is flashing the binary takes the majority of the time for most of theses tests, so the testing time will increase quite a bit if you add 20 binaries.

@andresag01
Copy link
Author

andresag01 commented Sep 29, 2016

@sbutcher-arm, @yanesca: I have rebased the changes and split the selftests into four functional components as previously discussed, but this is still failing the build test in some platforms. We could split these into even smaller parts.

@bridadan
Copy link
Contributor

/morph test

@mbed-bot
Copy link

Result: FAILURE

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

/morph test

Output

mbed Build Number: 1005

Build failed!

@bridadan
Copy link
Contributor

@andresag01 I know you said some platforms are failing, just reran the CI to get a feel for what is still affected.

@simonbutcher
Copy link
Contributor

Examining the problem, it looks as if some tests (and also functions and features) won't fit on some devices without target specific optimisations. That means that we can't adopt a 'on configuration of tests will suit all targets' approach, and we'll need to find some way to configure tests per target - which we can't do today.

Because the immediate need is to test entropy sources, and for the sake of getting into the test framework some tests we can build on, we've removed all self-tests apart from entropy and SHA-2, which hopefully should be small and simple enough to run on all devices. From there we can expand the set of tests in later PR's.

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 30, 2016

/morph test

@mbed-bot
Copy link

Result: SUCCESS

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

/morph test

Output

mbed Build Number: 1011

All builds and test passed!

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

Successfully merging this pull request may close these issues.

10 participants