DO NOT MERGE - Update Mbed TLS to version 2.7.0

[k-stachowiak]

Description

This pull request updates the Mbed TLS feature to the version 2.7.0

Status

READY

Migrations

See Mbed TLS 2.7.0 release notes for migration necessity/opportunity.

The example applications have been confirmed to build with ARM and ARM_GCC compiler and run on the K64F target.

Related PRs

None

Todos

None

Deploy notes

None

[0xc0170]

/morph build

[mbed-ci]

Build : FAILURE

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

[0xc0170]

@k-stachowiak Can you review the build failures ?

For multiple boards, these 2 example fails:

# mbed-os-example-tls-tls-client NUCLEO_F429ZI GCC_ARM
# mbed-os-example-tls-authcrypt NUCLEO_F429ZI GCC_ARM

The error: ETH redefined ?

[k-stachowiak]

@0xc0170 I'm on it

[k-stachowiak]

After running one of the tests locally, namely:

mbed test --compile -m MBED_CONNECT_ODIN -t ARM -DMBED_HEAP_STATS_ENABLED=1 -DMBED_STACK_STATS_ENABLED=1 -DMBED_TRAP_ERRORS_ENABLED=1 -c

I can confirm the linker errors. Also I tried running the same test against ARM_GCC, and it worked - I verified that the particular tests failing to build for ARM were successfully built with ARM_GCC.
By looking at the Mbed TLS code I can see that the symbols not being found by the linker are:

• marked with the __attribute__((deprecated)) (I don't think it matters in this context),
• only defined in the header file (however marked as inline).

I speculate that for some reason, in some cases the inline functions may not be emitted into the object files (e.g. when they are not included, obviously), but I can't see how that would work with one toolchain and not the other. I will investigate this clue.

I remember @Patater and @andresag01 discussing the introduction of this header-only deprecation layer, so maybe they can comment on it having impact on the ARM linker?

[andresag01]

@k-stachowiak: I do not know what is the situation with GCC, but in principle this should NOT work because Mbed TLS 2.7.0 renames the MD functions that are replaced by alternative implementations. Therefore, the symbols such as mbedlts_md5_starts() no longer when the hardware acceleration is enabled because the declarations for those functions inline or no inline are all within the #if defined(MBEDTLS_<MD>_ALT) directives. For example https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/md5.h#L42. Therefore the symbols are not in there and the linker fails. Note that the targets that do have hardware acceleration define the OLD symbols, but that would not work anyways because the rest of Mbed TLS expects the symbols to be <something>_ret(). I think that if you want this PR merged you probably need this as well.

[andresag01]

Also, another note. When compiling with ARMCC I get the error:

Error: L6218E: Undefined symbol mbedtls_md5_finish (referred from /home/andama01/Repos/mbed-os1/BUILD/tests/MBED_CONNECT_ODIN/ARM/targets/TARGET_STM/TARGET_STM32F4/TARGET_STM32F439xI/TARGET_MODULE_UBLOX_ODIN_W2/sdk/TOOLCHAIN_ARM/libublox-odin-w2-driver.ar(cb_md5.o)).

It seems that some UBLOX diver is using the old MD functions as well. You need to get this patched up as well, I suggest you contact someone from UBLOX about this.

[k-stachowiak]

@0xc0170 From what I gathered the ETH redefinitions are just warnings. They seem harmless (i grepped the entire code base and all the instances of this define are identical) and while should be fixed it is probably beyond the scope of this PR. The two issues that cause compiler or linker errors are:

• The aforementioned linker errors explained by @andresag01,
• "This hardware does not have an entropy source." preprocessor error for certain targets.

I am investigating possible ways of resolving those.

[0xc0170]

ublox provided a new update to one of the PR that was updating networking.

It seems that some UBLOX diver is using the old MD functions as well. You need to get this patched up as well, I suggest you contact someone from UBLOX about this.

Does this mean this update contains breaking changes? If you can point to them ?

cc @ARMmbed/team-ublox

[mazimkhan]

@k-stachowiak I agree with @andresag01 that you would need #5973 before this PR.
But #5973 also depends on this because PR for removing use of old API. To break this circular dependency you can provide old API wrappers in #5973 and get that PR to build and pass CI. Once that is merged this PR should also pass CI.

[cmonr]

Blocking PR has been merged in. Feel free to rebase when ready to continue!

[k-stachowiak]

/morph build

[adbridge]

@k-stachowiak As Cruz already mentioned please remove your merge commits and do a proper rebase against master. This PR will not be accepted as it currently stands. Thanks. Also please do not attempt to kick off CI builds, that is the maintainers job. Also please be aware of the 7 rules of good commit titles and messages. You can find guidance here https://os.mbed.com/docs/v5.7/reference/guidelines.html

[k-stachowiak]

@adbridge Thank you for your remarks. I will follow the rules.

[mbed-ci]

Build : FAILURE

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

[0xc0170]

I reviewed test results, the tls examples contain errors, please review

[andresag01]

Note that this is a major change to the config.h. Unless this PR includes changes on how to configure Mbed TLS in Mbed OS in another way this is going to break pretty much every application that uses Mbed TLS in Mbed OS. Could you please explain why these changes are here?

[k-stachowiak]

This change is a result of the automatic import process. It seems like some kind of an auto merge error. I will make sure there are no unnecessary differences between this tree and the upstream one.

[andresag01]

I just realised that this might also not work even after merging #5973. I do not think that all the new functions used by Mbed TLS are defined in the target's headers. For example: mbed-os/features/mbedtls/targets/TARGET_STM/sha256_alt.h is missing mbedtls_internal_sha256_process(). Instead, it looks like #5973 introduced a new symbol:

int mbedtls_sha256_process( mbedtls_sha256_context *ctx, const unsigned char data[ST_SHA256_BLOCK_SIZE] )

[k-stachowiak]

Branch cleaned up, but still needs work:

• solving ublox binary drivers linking issue (partner contacted)
• clarification of the changes in the process functions in the MD API
• resolution of mbed-os-example-tls compiler error

[ciarmcom]

ARM Internal Ref: IOTSSL-2101

[Patater]

This should be closed in favor of #6210.

[adbridge]

@k-stachowiak @Patater Please close this if you are sure it is being superseded by #6210

[k-stachowiak]

Closing in favor of #6210.