TARGET_NUMAKER_PFM_NUC472 dependency on mbed TLS

[sg-]

Description

• Type: Bug
• Priority: Major

---

Bug

Target
TARGET_NUMAKER_PFM_NUC472

Toolchain:
GCC_ARM, ARM, IAR

Scan: TARGET_NUMAKER_PFM_NUC472
Compile [  1.7%]: aes_alt.c
[Error] aes_alt.c@25,0:  #5: cannot open source input file "mbedtls/config.h": No such file or directory
"C:\Jenkins\workspace\mbed-2-build-library\targets\TARGET_NUVOTON\TARGET_NUC472\crypto\aes\aes_alt.c", line 25: Error:  #5: cannot open source input file "mbedtls/config.h": No such file or directory
C:\Jenkins\workspace\mbed-2-build-library\targets\TARGET_NUVOTON\TARGET_NUC472\crypto\aes\aes_alt.c: 0 warnings, 1 error

mbed OS 2 doesn't have a release of mbed TLS supported or delivered. TARGET_NUMAKER_PFM_NUC472 HAL dependency on it for hw acceleration. It seems this target should only support a mbed 5 release

@ccli8

[ccli8]

@sg- We want also to be compatible with mbed OS 2. Is there an approach, e.g. conditional compile, to exclude these codes for mbed OS 2?

[sg-]

Not at the moment. Are these drivers specifically for hardware acceleration covering parts of mbed TLS?

[ccli8]

@sg- Yes. These drivers (aes_alt.c, des_alt.c, sha_alt.c) are hardware acceleration for mbed TLS's crypto modules.

[cyliangtw]

@sg- After review all global macros of mbed OS 5.x and mbed OS 2.0, we can't find the macro to specify which one is OS 5.x . Maybe, to create target folder in //features/mbedtls and restructure crypto-hal into it.

[sg-]

@ccli8 thanks for the feedback. I'll have a chat with the mbed TLS maintainers and see how they suggest we handle this.

[0xc0170]

There was this same question asked already this week few times, time to progress this.
How to distinguish mbed 2 vs mbed 5. There's an open pull request to add MBED_VERSION macro (major/minor/patch). This however is proposed just for mbed 5. We could do this for mbed 2. Reference: #3096

Lets take some code from there and illustrate how it can be done:

#if defined(MBED_CONF_RTOS_PRESENT)
# we got RTOS present, this is valid only for mbed 5
#define MBED_MAJOR_VERSION 5
#define MBED_MINOR_VERSION 2
#define MBED_PATCH_VERSION 0

#else
// mbed 2
#define MBED_MAJOR_VERSION 2
#define MBED_MINOR_VERSION 0
#define MBED_PATCH_VERSION MBED_LIBRARY_VERSION
#endif

hacky to use MBED_CONF_RTOS_PRESENT , any other proposals to resolve this? Should tools define a symbol and we could use that for this version macros? These version macros could be then used to get what MAJOR an app is running on.

@c1728p9 @geky @theotherjimmy @sg- @pan-

Addition: I hijacked this thread as I found it related, but the main question for this issue stays why mbedtls is required for the driver. we might take this discussion to the separate issue, let me know, I'll redirect it

[geky]

Another option to consider, what if we provided MBED_CONF_MBEDTLS_PRESENT? This would highlight the specific dependency of the driver and has worked surprisingly well for the rtos.

[pan-]

@geky Indeed, it would also work for application using mbed SDK and importing mbed TLS.
I wonder why this alternative implementation of aes lives in the drivers; I'm not sure that the code pointed out should live in the OS, it is not a driver, it is an implementation for an external library.

[sg-]

I'm not sure that the code pointed out should live in the OS, it is not a driver, it is an implementation for an external library.

mbed TLS is integrated in mbed OS and this is a device implementation which should live with the device. We're missing a mbed C HAL for this.

[pan-]

We're missing a mbed C HAL for this.

That makes sense now.
What will be the pattern ? An abstraction in the HAL which will be implemented by the targets and an alternative AES implementation based on this abstraction ?